Provides tools for interacting with Construct 3 projects, including documentation search, project querying (objects, eventsheets, layouts), project mutation (creating/updating/deleting objects, events, layouts), animation management, project analysis (dependency graph, performance audit, validation), and scripting support (reading/writing JavaScript files).
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., "@ultimate-construct3-mcp search documentation for touch input"
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.
Unified MCP server for Construct 3 — offline documentation, project read/write, analysis, and scripting support. 44 tools in a single server.
{
"mcpServers": {
"construct3": {
"command": "node",
"args": ["path/to/ultimate-construct3-mcp/dist/index.js", "path/to/your/c3-project"]
}
}
}{
"mcpServers": {
"construct3-docs": {
"command": "npx",
"args": ["-y", "ultimate-construct3-mcp"]
}
}
}Related MCP server: GMS2 MCP Server
Tool | Description |
| Full-text search across all Construct 3 documentation |
| Get full markdown content of a documentation topic |
| List all available documentation topics |
| List categories with topic counts |
| Get Actions/Conditions/Expressions for a plugin or behavior |
| Search for code examples from the documentation |
Tool | Description |
| List all object types (with optional filter) |
| List all event sheets |
| List all layouts |
| List all families |
| Get full JSON of an object type |
| Get full JSON of an event sheet |
| Get full JSON of a layout |
| Search objects by name pattern |
| Get project metadata and statistics |
Tool | Description |
| Create a new object type (Sprite, Text, Audio, etc.) |
| Add/remove variables, behaviors, change global status |
| Delete an object (with reference checking) |
| Create a new event sheet |
| Add group/function/variable/include/comment events |
| Add block events with conditions + actions (recursive) |
| Modify existing block events |
| Delete an event sheet (with reference checking) |
| Delete individual events by SID |
| Create a new layout |
| Place object instances on layout layers |
| Update layout properties |
| Delete a layout (with reference checking) |
| Update project name, version, author, description |
Tool | Description |
| Add animations with auto-generated placeholder PNGs |
| Update speed, looping, ping-pong settings |
Tool | Description |
| Event sheet include hierarchy (Mermaid/JSON) |
| Function definitions and call sites |
| Object usage graph (events, layouts, families) |
| Find unused objects |
| Track asset usage (sound, image, font, video) |
| Heuristic performance audit |
| 13-check integrity validation |
| Group active/disabled status across event sheets |
Tool | Description |
| List all JavaScript files in the project |
| Read a script file's contents |
| Create or modify a JavaScript file |
| Read any project file (JSON or text) |
| Write a JSON file to the project |
project-info — Project metadata
project-structure — Full project structure overview
project-addons — Used plugins, behaviors, effects
object-details — Object type details (template)
eventsheet-details — Event sheet details (template)
layout-details — Layout details (template)
analyze_project — Full project analysis
find_object_usage — Find where an object is used
explain_eventsheet — Explain an event sheet's logic
review_game_logic — Review game architecture
document_object — Generate object documentation
optimize_project — Get optimization suggestions
Supported: en, es, pt-br, fr, de, it, ja, ko, zh, ru, tr
All doc tools accept a lang parameter. Falls back to English if a topic isn't translated.
c3-docs-scrape --all --lang en
c3-docs-scrape --category plugins --lang en
c3-docs-scrape --topic sprite --lang esgit clone <repo>
cd ultimate-construct3-mcp
npm install
npm run build
npm testMIT
Construct 3 is developed by Scirra Ltd. This project is not affiliated with Scirra.
Get the Actions, Conditions, and Expressions (ACE) reference for a Construct 3 plugin or behavior.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language code (default: en) | |
| plugin | Yes | Plugin or behavior slug (e.g. 'sprite', 'platform', 'tween') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only lookup but does not state whether the reference is static or version-specific, what happens if an unknown plugin is passed, or what form the response takes.
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 efficient sentence with the key resource and scope front-loaded. Every part of the sentence earns its place.
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 two-parameter lookup tool with no output schema, the description covers the basic purpose but leaves behavioral and return-format gaps. Given the absence of annotations, it should say more about what the agent will receive and how errors are handled.
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 100%, so both parameters are already documented in the schema. The description adds only the expansion of the ACE acronym and confirms that the plugin parameter accepts either a plugin or behavior slug, which is a marginal addition over the 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 states a specific verb and resource: retrieving the Actions, Conditions, and Expressions reference for a named Construct 3 plugin or behavior. It is clear what the tool returns, though it does not explicitly differentiate itself from sibling tools like get_doc or search_docs.
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 usage is implied: use this when you need ACE details for a specific plugin or behavior. However, the description does not say when to prefer this over search_docs or get_doc, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full markdown content of a Construct 3 documentation topic.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language code (default: en) | |
| topic | Yes | Topic slug (e.g. 'sprite', 'platform', 'layouts') | |
| category | No | Category to disambiguate topics with same slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries full burden. It does disclose the return format ('full markdown content'), which is genuinely useful, but says nothing about read-only safety, behavior for invalid/missing topics, or language fallback for the 'lang' parameter.
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 zero waste. The verb and the payload format both land immediately.
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 read-only retrieval tool with fully documented parameters, the definition covers purpose and return format adequately. The main missing piece is how to discover valid topic slugs, which matters for a lookup tool in a family that includes list_topics and search_docs.
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 100% — every parameter including the enum-constrained 'category' is documented inline. The description adds no parameter-level detail beyond what the schema already provides, so baseline 3 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?
States a specific verb and resource: 'Get the full markdown content of a Construct 3 documentation topic.' This clearly separates it from search_docs and list_topics by emphasizing full content retrieval of a single topic, though it doesn't explicitly name the siblings.
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 gives no guidance on when to use this versus search_docs, list_topics, or get_examples, and doesn't say where valid topic slugs come from. The choice is left entirely to inference from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for code examples and snippets from the Construct 3 documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language code (default: en) | |
| limit | No | Max results (default: 10) | |
| query | Yes | Search query for code examples (e.g. 'collision', 'tween', 'spawn') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it delivers only one sentence. It does not disclose result ranking, what a returned snippet contains (title? code block? source URL?), whether results are truncated or paginated, or how the lang parameter affects matching.
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 zero filler, and the resource type appears early. It is efficient but borders on under-specified rather than tight.
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?
Three well-documented parameters and no output schema mean the description should at least characterize the return shape for a search tool, which it does not. It is minimally adequate to call the tool but leaves an agent guessing about result format.
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 100%, so query, lang, and limit are already documented including defaults and bounds. The description adds nothing about parameter behavior (e.g. whether lang filters or translates results), so the baseline 3 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?
States a specific verb ('Search') plus resource ('code examples and snippets') plus source scope ('Construct 3 documentation'), which differentiates it from generic doc-reading siblings like search_docs and get_doc. It stops short of explicitly naming the sibling it replaces, so an agent must infer the boundary.
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 is only implied by the resource type: reach for this when you need runnable snippets rather than prose docs. There is no explicit when/when-not statement and no mention of search_docs, get_ace_reference, or get_doc as alternatives for related needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all documentation categories with descriptions and topic counts.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language code (default: en) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the burden. It does disclose the response composition (category descriptions and topic counts), which is genuinely useful since there is no output schema, but says nothing about ordering, pagination, or whether categories are scoped by workspace — 'list all' implies no pagination but does not confirm it.
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?
One sentence, front-loaded with the verb and resource, with the return payload appended. Nothing superfluous.
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-required-parameter read tool with no annotations and no output schema, the description covers what the tool does and what comes back, which is enough to call it correctly. Only language-fallback and ordering behavior are left unspecified.
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 optional 'lang' parameter is fully documented in the schema (100% coverage), so the schema does the heavy lifting. The description adds nothing about language behavior — e.g. whether missing translations fall back to English — which is the one semantic gap the schema leaves open.
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 and resource ("List all documentation categories") plus the payload it returns (descriptions and topic counts). This is clearly separable from list_topics and search_docs by the resource noun alone, though it never names a sibling to sharpen the distinction.
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 when-to-use or when-not-to-use guidance, and no alternative is mentioned. An agent must infer that this is a discovery/overview call versus list_topics or search_docs entirely on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Construct 3 documentation topics, optionally filtered by category.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language code (default: en) | |
| category | No | Filter by category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden, and it does convey read-only intent via 'List' and the completeness claim 'all available'. However, it does not disclose the return shape, whether results are grouped or paginated, or how lang affects output.
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 efficient sentence with the action front-loaded and zero repetition. It is slightly terse given it is the only source of behavioral detail.
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 two-parameter read-only list tool with full schema coverage, the essentials are present, but the absence of an output schema means the description should say something about what is returned. That gap keeps it at minimum viable.
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 100%, so both lang and category are already documented in the schema with an enum for category. The description adds only the 'optional' framing, so baseline 3 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?
States a specific verb+resource ('List all available Construct 3 documentation topics') with the optional category filter. It distinguishes the tool from search_docs and get_doc implicitly, but does not clarify how it differs from the sibling list_categories, leaving mild ambiguity.
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 phrase 'optionally filtered by category' implies when to apply the filter, but there is no explicit guidance on when to use this tool versus search_docs, list_categories, or get_doc. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across Construct 3 documentation. Returns matching topics with relevance-scored snippets.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language code (default: en) | |
| limit | No | Max results (default: 10) | |
| query | Yes | Search query | |
| category | No | Filter by category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that results are matching topics with relevance-scored snippets, which is useful return context, but it does not discuss pagination, result ordering, or operational constraints beyond what the schema implies.
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 efficient sentences with the core operation front-loaded. Every sentence adds useful information, and there is no redundant or filler 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?
Given the low complexity, complete schema descriptions, and absence of an output schema, the description provides enough context to call the tool correctly. The main missing element is explicit routing guidance versus sibling tools.
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 100%, so all four parameters are already documented in the input schema. The description adds no parameter-specific semantics beyond the general idea of a full-text search, so baseline 3 is appropriate.
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: full-text search across Construct 3 documentation. It distinguishes the operation from list/get siblings by emphasizing search and relevance-scored snippets, but does not explicitly name alternatives such as get_doc or list_topics.
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 is implied by 'full-text search' and returning matching topics, so an agent can infer this is for query-based lookup. However, the description gives no explicit when-to-use guidance, exclusions, or comparison to sibling tools like get_doc or list_topics.
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.
v2.0.0get_ace_referenceget_docget_exampleslist_categorieslist_topicssearch_docsScored across 6 tools
Each tool targets a distinct facet of the docs surface (search, browse topics, browse categories, fetch topic, ACE reference, examples). The only mild overlap is between search_docs and get_examples, since both are query-style lookups, but the example-specific description makes the boundary clear enough.
All names follow a clean verb_noun snake_case pattern (search_*, list_*, get_*), with verbs matching the operation type. No mixed conventions.
Six tools is a well-scoped set for a documentation lookup server — one query tool, one content fetcher, two browsing tools, plus ACE and example lookups. Each earns its place without redundancy.
The surface covers the full docs workflow: browse categories/topics, search, fetch full content, and specialized ACE/example lookups. Minor gaps exist (e.g. no versioned docs or plugin-name discovery for ACE), but agents can work around them via search.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Official Duck Framework MCP server for AI-assisted development and project scaffolding.
An MCP server that gives your AI access to the source code and docs of all public github repos
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
