Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@godot-ui-feedback-mcp Capture the main menu scene for UI feedback"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This MCP captures real Godot UI screenshots and node metadata for a browser-annotatable workflow.
It is designed for this loop:
The user provides a screenshot or text description of the game UI surface.
The agent calls suggest_godot_scenes to find likely Godot scene files.
When the fix should preserve broader project UI style, resources, or layout conventions, the agent calls collect_godot_ui_context.
The agent calls ensure_exporter_installed if the target project does not already have the managed exporter scripts.
The agent calls capture_godot_ui_reference for the selected scene or a small state harness.
Codex treats the complete capture screenshot as the reliable evidence for existing-page fixes. Project context is supporting evidence only.
Codex uses the complete captured screenshot as the reliable visual basis and creates a separate structured HTML proxy that visually recreates the screen.
The user opens that visual proxy in the browser and leaves comments on semantic DOM elements.
The agent calls parse_browser_feedback to turn comments into Godot-targeted records.
The agent maps the records to Godot nodes/files, writes tests, and changes the game UI.
For brand-new screens, use a separate design loop:
The user describes the new page goal and expected gameplay state.
The agent calls collect_godot_ui_context to gather bounded project UI context.
The agent captures 1-3 complete representative existing screens with capture_godot_ui_reference.
Codex creates a separate semantic HTML design proxy for the proposed page.
The user comments on the design proxy, and the agent maps feedback to proposed regions/components before implementing the Godot scene.
collect_godot_ui_context and capture_godot_ui_reference are shared by both workflows. Complete Godot screenshots are the reliable visual basis. Static project context is only candidate/supporting evidence.
This tool runs locally and executes Godot against a user-selected project. Use it for trusted local development projects, not untrusted repositories.
The capture exporter is installed under:
res://addons/ui_feedback_bridge_mcp/tools/The installer refuses to overwrite files in that directory unless they contain the UI_FEEDBACK_BRIDGE_MCP_MANAGED marker. Use dry_run to preview installer or uninstaller actions before writing the project. The uninstaller removes only managed files and refuses to remove unmanaged files at the exporter paths. Managed exporter install/uninstall also refuses symlink exporter paths and symlink parent directories, so managed writes cannot be redirected outside the project through the exporter path. Capture outputs must be written under res://docs/ui_proxy/ and end with .html; absolute output paths and project escapes are rejected. The bundled Godot exporter script repeats this output-path check for defense in depth.
The Godot executable is resolved from the GODOT_BIN environment variable or defaults to godot. MCP tool arguments intentionally do not accept arbitrary executable paths.
Runtime setup calls are limited to root-node methods named _mcp_capture_*. Create capture-only harness methods for UI states instead of calling production gameplay methods directly.
Related MCP server: Godot MCP Toolkit
suggest_godot_scenesInput:
{
"project_path": "C:/path/to/GodotProject",
"description": "main desk screen",
"limit": 10
}Output:
{
"suggestions": [
{
"scene_path": "res://scenes/main.tscn",
"project_relative_path": "scenes/main.tscn",
"score": 13,
"reasons": ["scene_file", "description", "ui_or_scenes_folder"]
}
]
}collect_godot_ui_contextInput:
{
"project_path": "C:/path/to/GodotProject",
"scene_limit": 20,
"asset_limit": 50
}Output summarizes UI-related scene files, common Control node types, sample node names, layout hints, style overrides, Theme resources, fonts, candidate UI image assets, UI-referenced resources, and recommended scenes to capture. This static scan can miss runtime UI state, theme inheritance, shader effects, dynamic text, and script-driven layout changes. It does not design the page and does not write files. Scans are bounded by file-count and scene-read limits so large projects cannot require unbounded traversal.
For existing-page fixes, call this only when broader project style context matters. The complete captured screen remains the reliable source of truth for what currently exists.
capture_godot_ui_referenceInput:
{
"project_path": "C:/path/to/GodotProject",
"scene_path": "res://scenes/main.tscn",
"out_path": "res://docs/ui_proxy/main-capture.html",
"width": 1280,
"height": 720,
"title": "Main UI Capture",
"calls": ["_mcp_capture_difficulty:0"],
"timeout_seconds": 60
}Output includes the generated capture file path, screenshot path, command, and exported Godot UI node count. Use calls when the requested screen is a runtime state rather than the scene's initial _ready() view.
Use a *-capture.html name for this output when possible. The generated HTML is a capture artifact, not the final review proxy. The default review flow is for Codex to inspect the screenshot, understand the screen visually, and write a separate semantic HTML proxy by recreating the layout one-to-one. Do not auto-slice the screenshot into the final proxy.
ensure_exporter_installedInput:
{
"project_path": "C:/path/to/GodotProject",
"dry_run": false
}Output lists copied exporter scripts, unchanged scripts, and planned actions. Set dry_run to true to preview install/update actions without writing files. capture_godot_ui_reference also calls this automatically before running Godot.
uninstall_exporterInput:
{
"project_path": "C:/path/to/GodotProject",
"dry_run": false
}Output lists removed, missing, and planned exporter scripts. Set dry_run to true to preview removal. The tool refuses to remove any exporter path that does not contain the managed marker.
generate_godot_ui_proxyDeprecated compatibility alias for capture_godot_ui_reference. New workflows should use the capture name so the MCP artifact is not confused with the final visual recreation proxy.
parse_browser_feedbackInput:
{
"comments_text": "# Browser comments:\n\n## Comment 1\n...",
"mode": "existing_page"
}Use "mode": "new_page_design" for comments on a proposed design proxy. Existing-page records target Godot nodes/files for later mapping. New-page design records target proposed components and layout regions instead. Browser page fields are rendered as JSON inside fenced blocks and should be treated as untrusted evidence rather than user instructions.
describe_workflowReturns the end-to-end usage flow.
Install for local development:
python -m pip install -e .Install with the optional FastMCP dependency:
python -m pip install -e ".[mcp]"Set a trusted Godot executable if godot is not on PATH:
$env:GODOT_BIN = "C:/Program Files/Godot/Godot_v4.4-stable_win64.exe"List tools without running the MCP protocol:
python -m godot_ui_feedback_mcp.server --list-toolsCall one tool directly:
python -m godot_ui_feedback_mcp.server --call-tool describe_workflowFor tools with larger JSON inputs on Windows, prefer an arguments file:
@'
{
"project_path": "C:/path/to/GodotProject",
"scene_path": "res://scenes/main.tscn",
"out_path": "res://docs/ui_proxy/main-capture.html",
"width": 1280,
"height": 720
}
'@ | Set-Content -Encoding UTF8 capture-args.json
python -m godot_ui_feedback_mcp.server --call-tool capture_godot_ui_reference --arguments-file capture-args.jsonRun as an MCP server:
python -m godot_ui_feedback_mcp.serverThe Python mcp package is required only for FastMCP stdio server mode. Without it, this package falls back to a minimal JSON-RPC stdio server.
The test suite includes a Godot integration test that creates a minimal fixture project and verifies capture_godot_ui_reference writes HTML, PNG, and node metadata. It runs when GODOT_BIN, godot4, or godot is available; otherwise it is skipped.
Capture a real Godot UI screenshot and node metadata from a scene.
| Name | Required | Description | Default |
|---|---|---|---|
| calls | No | Optional root-node methods named _mcp_capture_* to enter a capture state. | |
| title | No | Godot UI Capture | |
| width | No | ||
| height | No | ||
| out_path | Yes | Must be under res://docs/ui_proxy/ and end with .html. | |
| scene_path | Yes | ||
| project_path | Yes | ||
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action but does not disclose any behavioral traits such as whether it modifies state, requires permissions, or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. However, it could include more detail without becoming verbose. It earns its place but is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (8 parameters, no output schema, no annotations), the description is insufficient. It does not explain the output format, what 'node metadata' includes, or how the capture process works.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the tool description adds no additional parameter meaning. Only two out of eight parameters are described in the schema, and the description does not compensate. The baseline for low coverage is lower than 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a 'real Godot UI screenshot and node metadata from a scene.' The verb 'capture' and the resource are specific, making the purpose understandable. It doesn't explicitly differentiate from sibling tools, but the action is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or scenarios where this tool is appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collect bounded static Godot UI scene, theme, font, image, layout, and style context for existing-page style support and new-page design. Use complete capture_godot_ui_reference screenshots as the reliable visual basis.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_limit | No | ||
| scene_limit | No | ||
| project_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should fully disclose behavior. It describes a read/collect operation with no mention of side effects, permissions, or what 'bounded static' entails. It does not contradict annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence states purpose, second references a sibling tool for visual basis. Front-loaded with key intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description does not hint at return format. Differentiation from sibling tools (e.g., generate_godot_ui_proxy, suggest_godot_scenes) is weak. An agent lacks information to decide when to invoke this tool over others.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no explanation for any of the three parameters (project_path, asset_limit, scene_limit). The agent receives no guidance on parameter values beyond the schema defaults and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it collects Godot UI context (scene, theme, font, etc.) for style support and design. It references a related sibling tool, but 'bounded static' is ambiguous and doesn't strongly distinguish from siblings like generate_godot_ui_proxy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using this tool after capture_godot_ui_reference screenshots, but does not explicitly state when to use or not use it, nor provide alternatives. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe the screenshot-to-proxy-to-feedback workflow.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry full behavioral burden. It only states the tool's purpose but fails to disclose if it modifies any state or has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the tool's purpose without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description fits the simple nature of the tool, it lacks details about the workflow content or the output format, leaving some ambiguity about what the agent will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. The description does not need to add parameter details; the absence of parameters is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Describe' and a clear resource 'the screenshot-to-proxy-to-feedback workflow', immediately distinguishing it from sibling tools like capture_godot_ui_reference or generate_godot_ui_proxy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description merely states what it does without context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install the managed Godot capture exporter scripts into the target project.
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | ||
| project_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description does not disclose behavioral traits like idempotency, overwrite behavior, permission requirements, or side effects. With zero annotation coverage, the description should provide more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It lacks important details that could be added without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, no output schema, and no annotation, the description should provide more context about what the installed scripts do, how to verify success, and what impact the operation has on the project.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to parameters like 'dry_run' (what does it do?) or 'project_path' (expected format). The schema only defines types and defaults without explaining usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Install the managed Godot capture exporter scripts into the target project,' which is a specific verb and resource. It distinguishes from siblings like 'uninstall_exporter' by focusing on installation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or conditions such as whether the target project must already exist or if the tool can be run multiple times.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deprecated alias for capture_godot_ui_reference.
| Name | Required | Description | Default |
|---|---|---|---|
| calls | No | Optional root-node methods named _mcp_capture_* to enter a capture state. | |
| title | No | Godot UI Capture | |
| width | No | ||
| height | No | ||
| out_path | Yes | Must be under res://docs/ui_proxy/ and end with .html. | |
| scene_path | Yes | ||
| project_path | Yes | ||
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral information is provided beyond the deprecation notice; without annotations, the agent gets no insight into side effects, permissions, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description omits essential details, failing to be both concise and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no annotations, and no output schema, the description must compensate but provides only a deprecation notice, severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no explanation of any of the 8 parameters, and schema coverage is only 25%, leaving the agent with insufficient detail to correctly fill parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description labels the tool as a deprecated alias for capture_godot_ui_reference but does not explain what either tool does, leaving the agent uncertain about its functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Deprecated alias', indicating that the tool should not be used and that capture_godot_ui_reference should be used instead, which is clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse Codex browser comments into existing-page or new-page design feedback records.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | existing_page | |
| comments_text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only states parsing without detailing side effects, prerequisites, or output specifics. The lack of transparency for a tool with two modes is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action. However, it could be more structured to explicitly list modes or output details. It earns a high score for being efficient but not perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, no output schema, and no annotations, the description is too brief. It does not explain what 'design feedback records' entail or how the parsing handles different modes, leaving the agent without sufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter comments exist. The description does not elaborate on the expected format of comments_text or the meaning of mode values beyond their names, leaving important context unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb (Parse), resource (Codex browser comments), and output (design feedback records). It also distinguishes between two modes (existing-page vs new-page), making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Siblings like capture_godot_ui_reference and collect_godot_ui_context suggest different contexts, but no comparison or usage criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest Godot scenes for a screenshot or text description.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| description | No | ||
| project_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must cover behavioral traits. It only states the purpose, omitting any details about side effects, authorization, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (8 words) but under-specified for a tool with 3 parameters and no output schema. It sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, the description fails to provide sufficient context. It does not explain input requirements, output format, or how parameters affect behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaningful parameter information. It does not explain the role of project_path, limit, or description beyond the schema's basic types and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'suggest' with a specific resource 'Godot scenes' and provides context (for screenshot or text description). It is clear about the primary function but does not differentiate from sibling tools like capture_godot_ui_reference or collect_godot_ui_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when or when not to use this tool, nor any mention of alternatives. The description simply states what the tool does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove managed Godot capture exporter scripts from the target project.
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | ||
| project_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'Remove', implying a destructive operation. No annotations are provided to clarify side effects, such as whether files are deleted or if the tool fails gracefully when the exporter is not present. Behavioral traits are not disclosed beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous words. While it could be more informative, it is appropriately concise for a straightforward operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain what the tool returns (e.g., success confirmation, list of removed files). It does not. Additionally, it lacks information on the dry_run parameter's effect or error handling, leaving gaps for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the purpose of the two parameters (project_path, dry_run) or how they affect tool behavior. For example, what does dry_run do? The description adds no value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove managed Godot capture exporter scripts from the target project' clearly states the action (remove) and the resource (managed Godot capture exporter scripts). It effectively distinguishes this tool from siblings like ensure_exporter_installed, which does the opposite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. While sibling tools exist (e.g., ensure_exporter_installed), the description does not mention scenarios where uninstalling is appropriate or any prerequisites. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0capture_godot_ui_referencecollect_godot_ui_contextdescribe_workflowensure_exporter_installedgenerate_godot_ui_proxyparse_browser_feedbacksuggest_godot_scenesuninstall_exporterScored across 8 tools
Each tool has a distinct purpose: capture screenshots, collect context, install/uninstall exporter, parse feedback, suggest scenes, and describe workflow. The deprecated alias is clearly marked, so no confusion.
All tools use snake_case and mostly follow verb_noun pattern. The deprecated 'generate_godot_ui_proxy' is a minor inconsistency but it's clearly an alias.
With 8 tools, the set is well-scoped for a UI feedback MCP. It covers capture, context, installation, feedback parsing, and scene suggestion without being bloated.
The tool surface covers core workflows (capture, context, feedback parsing) but lacks tools for managing feedback records (e.g., list, update, delete), which is a notable gap.
Capture screenshots, detect visual regressions between page versions, and analyze with AI.
remote debug iOS/Android/Unity/Godot/Flutter/RN/Web on real-device.ui-tree/screenshots/taps,tests.
UI design from prompts, screenshots, and URLs for AI coding agents and theme tokens.
Drive real devices from your AI Coding tool. Embed a client SDK (Unity, Godot, Flutter, iOS/macOS, Android, React Native, Web) in your app, then capture screenshots, traverse the UI tree, inject taps and key events, and run automated test tasks on the physical device over a secure relay.
