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., "@pixel-composer-mcp open D:/art/wizard.pxc and render all export nodes"
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.
MCP server that lets an agent drive Pixel Composer
(Steam build, Windows): open a .pxc, read its node graph, change input values, render every Export node.
Talks to the app's built-in Remote Terminal addon (WebSocket, 127.0.0.1:22400). Each command
goes through the in-app console, which can call any GML function by name (load_file_path, exportAll, …).
On every server start, Addons/__init.json is checked and "Remote Terminal" is appended if missing
(other enabled addons are kept). The first start enables it; later starts only check.
If the port is already open (you started Pixel Composer yourself), the server attaches to it.
Otherwise it launches the app with SteamAppId=2299510 (Steam builds abort without it) and reads its stdout.
If the app is running without the port (started before the addon was enabled), restart it.
A Pixel Composer window appears while working. --headless is not used: in 1.22.x it loads a stub theme
missing keys that every Surface input needs, so almost no real project loads.
Related MCP server: compositor-mcp
tool | what it does |
| load a |
| nodes, types, stored input values by index, connections (reads the file) |
| edit a static input value in the file and reload it |
| run every Export node, wait until outputs stop changing, return file paths |
| raw console command, e.g. |
| mode, project, log tail / quit the app (only if this server launched it) |
Limits: input names are not stored in .pxc, so inputs are addressed by index. The output file
extension comes from the Export node's format setting (asking for x.png can produce x.gif).
Image sequences (Export input 3 = 1) need %f in the name template (input 2, e.g. %d%n_%f),
otherwise every frame overwrites the same file.
Paths with spaces are loaded from a copy in %LOCALAPPDATA%\PixelComposer\mcp_work\ because the
console splits arguments on spaces. In attach mode there is no app log, so export detects
completion by watching the Export folders.
{
"mcpServers": {
"pixel-composer": {
"command": "uv",
"args": ["run", "--directory", "D:/MCPS/pixel-composer-mcp", "pixel-composer-mcp"]
}
}
}Environment overrides: PXC_DIR (install folder), PXC_DATA_DIR (default %LOCALAPPDATA%\PixelComposer),
PXC_TERMINAL_PORT (default 22400).
Remote Terminal has no authentication and executes arbitrary app functions. It listens on all interfaces
(::), so keep port 22400 blocked from the network by the firewall. It stays enabled for normal app launches
too; turn it off in Pixel Composer's addon panel if you stop using this server.
uv run pytestQuit Pixel Composer if this server launched it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the important guard: the tool will only quit an instance this server started, implying a no-op or error otherwise. However, for a terminate operation it says nothing about unsaved state, whether the quit is graceful or forced, or what happens to in-flight work — gaps that matter for a mutation of this severity.
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?
A single sentence that front-loads the action and qualifies it immediately. Nothing is redundant or padded.
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?
An output schema exists, so return values need not be explained, and a zero-parameter quit tool needs little more than what is given. The remaining shortfall is the absence of any note about unsaved data or what the caller should expect after a quit.
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 takes zero parameters, so there is nothing for the description to disambiguate; the empty schema is fully self-explanatory. Baseline 4 applies.
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 supplies a specific verb (quit) and resource (Pixel Composer) that the ambiguous name 'close' does not, and the conditional clause distinguishes it from every sibling, none of which terminate the application. It stops short of an explicit 'unlike X, use this when…' contrast, but the purpose is unmistakable.
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?
'if this server launched it' is a concrete precondition that tells the agent when this tool is applicable and implicitly when it is not (an externally launched instance). It does not name alternatives, but no sibling offers an equivalent action, so the context is clear without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run every Export node of the open project and wait until the output files stop changing.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it runs all Export nodes and blocks until output files stop changing, which is useful, but it omits timeout behavior, error handling, side effects on project state, and permission requirements.
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?
A single, front-loaded sentence with no redundant text; it efficiently conveys the core action and wait condition.
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 no-annotation action tool with no output schema, the description should explain return values, timeout semantics, and failure modes. It covers the core action and blocking wait but leaves these gaps, making it only adequate.
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 sole parameter `timeout` has 0% schema description coverage and the description never mentions it. It does not clarify units (e.g., seconds), default behavior, or what happens when the timeout is reached.
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?
States a specific verb ('Run') and resource ('every Export node of the open project') plus the wait condition. It is clearly distinguishable from generic run_command but does not explicitly compare itself to any sibling.
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 versus run_command or status, no explicit prerequisite that a project must be open, and no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List nodes with their type, stored input values (by index) and connections. Reads the file, not the app.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses that the tool is a read operation against the file, not the live app, and describes the returned node data, but it does not cover path default behavior, error conditions, or whether the project must exist or be closed.
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 two short sentences and front-loads the main output structure before adding the important file-vs-app distinction. There is no wasted text.
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?
The description covers what the tool returns and its read-only nature, which is important because no output schema exists. It is still incomplete for an agent that needs to know how to set path or when this inspection is preferable to opening or checking 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 does not explain the optional path parameter. It implies a file is being read but does not say what path means, what happens when path is null, or whether the default targets a known project.
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 states a specific action and resource: it lists nodes and includes their type, stored input values by index, and connections. The phrase 'Reads the file, not the app' helps distinguish it from app-oriented siblings, though no sibling is named explicitly.
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 usage by clarifying that it reads the file rather than the app, which suggests when this tool is appropriate. However, it does not explicitly say when to use it instead of open_project, status, or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a .pxc in Pixel Composer, launching the app if needed (a window will appear).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that the app launches if needed and that a window will appear, but it omits other relevant behavior such as what happens if the file is missing, whether an existing window is reused, or what the tool returns.
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 front-loaded sentence with no wasted words. It immediately communicates the action, target, and key side effect.
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 simple one-parameter tool, the description covers the core action and launch behavior. However, with no annotations and no output schema, it does not explain success/failure behavior or what an agent should expect after invocation, leaving gaps for an open-mutation tool.
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 single required parameter has 0% schema description coverage, so the description must compensate. It implies that the path refers to a .pxc file, but does not specify whether it must be absolute, relative, or an existing file, leaving meaningful ambiguity.
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 states a specific verb and resource: opening a .pxc file in Pixel Composer. It is clear what the tool does, but it does not explicitly differentiate itself from siblings like inspect_project or status.
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?
There is no explicit guidance on when to use this tool versus alternatives such as inspect_project. The implied usage is only that it opens .pxc files, with no exclusions or context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a raw console command (e.g. 'set ', or any GML function name with space-separated args). Returns app log lines printed meanwhile (empty when attached).
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | ||
| command | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a return-behavior trait that isn't in any structured field (log lines printed meanwhile, empty when attached), but it says nothing about the obvious risk profile of arbitrary command execution, error handling, or what 'attached' means operationally.
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 short sentences, front-loaded with purpose then behavior, no filler. The phrase 'empty when attached' is slightly elliptical but the density is appropriate.
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?
An output schema exists, so return structure needn't be spelled out, and the description does describe the synchronous log output. However, for an un-annotated arbitrary-execution tool with an undocumented 'wait' parameter, the definition should say more about preconditions and failure modes.
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 coverage is 0%, so the description must compensate. It does a good job on the required 'command' parameter by showing accepted syntax variants, but the 'wait' parameter is left entirely undefined in both schema and description, including its unit and what it governs.
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?
Names a specific verb+resource ('send a raw console command') and gives concrete examples of the accepted forms ('set <global> <value>', GML function names with args). An agent immediately knows what this does; it just doesn't explicitly contrast with the sibling set_input, which is the structured alternative.
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?
There is no statement of when to reach for this over set_input or the other siblings, nor any prerequisite such as needing a project/attachment first. The examples imply a low-level escape hatch but the agent has to infer that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a node input's static value in the .pxc file (node = id, iname or name).
Reloads it in the app when it is the open project, so a following export uses the new value.
| Name | Required | Description | Default |
|---|---|---|---|
| node | Yes | ||
| path | No | ||
| index | Yes | ||
| value | Yes | ||
| reload | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose real behavior: it mutates the .pxc file on disk and reloads the project in the app only when that project is currently open. It omits what happens on failure (missing node, unwritable file), whether the prior value is recoverable, and what is returned.
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 short sentences with zero filler, front-loading the action and scope, then the side effect. Every clause carries information the agent needs.
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 mutation tool with no annotations, no output schema, and five parameters at 0% schema coverage, the description is too thin. Key gaps remain: meaning of `path` and `index`, accepted type/shape of `value`, and error or no-op behavior when the node or project is absent.
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% across five parameters, so the description must compensate — it only explains `node` (id/iname/name) and indirectly hints at `reload`. `path`, `index`, and `value` (untyped, no schema description) are left completely undefined, including whether `path` is a file or project path.
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 gives a specific verb and resource — set a node input's static value in the .pxc file — and clarifies that `node` may be an id, iname, or name. It is clearly distinguishable from every sibling (open_project, inspect_project, export, run_command, status, close), none of which touch node inputs.
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?
Usage context is implied rather than stated: the note that a reload makes 'a following export use the new value' tells the agent to call this before exporting. However, there is no explicit when-to-use/when-not guidance, no mention of prerequisites (project open, node existing), and no alternative named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connection mode (launched/attached/stopped), open project and recent app log.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It indicates that the tool returns connection state, open project, and recent log, which is useful, but it does not explicitly state that the operation is read-only or describe response formatting.
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, front-loaded sentence with no redundant text. Every element (connection mode, open project, recent log) contributes to understanding what the tool returns.
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 zero-parameter status tool with no output schema, the description sufficiently enumerates the returned information. It could be slightly more complete by clarifying response shape or read-only behavior, but it covers the essential content.
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 zero parameters, so there are no parameter semantics to explain. The schema is empty and fully covered, making this dimension essentially complete by default.
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 specifies the status data returned: connection mode (launched/attached/stopped), open project, and recent app log. It does not explicitly distinguish itself from the sibling inspect_project tool, but the enumerated return contents make the tool's purpose easy to infer.
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?
There is no explicit guidance on when to use this tool versus alternatives like inspect_project. Usage is only implied by the name 'status' and the listed fields, leaving the agent to infer the right context.
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.0closeexportinspect_projectopen_projectrun_commandset_inputstatusScored across 7 tools
Most tools have clearly distinct purposes: open_project launches the app, inspect_project reads the file, set_input mutates a node value, export runs export nodes, status reports connection, close quits. The only overlapping pair is set_input vs run_command, since a raw console command could also modify values, but the descriptions clarify that set_input targets node inputs specifically.
Most names follow a verb_noun pattern (open_project, inspect_project, set_input, run_command), with minor deviations where export, status, and close are bare verbs/nouns. The convention is still predictable and readable throughout.
Seven tools is well-scoped for a Pixel Composer control server, covering lifecycle (open/close/status), inspection, mutation, and export without padding. Each tool earns its place.
Lifecycle, inspection, mutation, and export are all covered, and run_command provides an escape hatch for anything missing (node creation, connections, GML calls). Some first-class operations like creating nodes or editing connections are absent, but the console fallback mitigates this.
Control Unreal Engine to browse assets, import content, and manage levels and sequences. Automate…
Blender-as-a-service for agents: search 3D assets, run Blender Python, or brief the studio agent.
Read a project's prompts, logs and agents, and send new work to the agent on your own machines.
Start and manage Reason cloud coding agents, projects and sessions from any MCP client.
