Provides sourced Roblox game-development knowledge, including tools to search logics, retrieve detailed write-ups, search code examples by Luau API, find related systems, and browse categories and logics.
Ask your assistant "how do I save player data without losing items?" and it finds the real mechanism, the pitfalls and the source links. Every logic is written up from DevForum threads, Creator Docs or GitHub repos, with links back.
Works with Claude Code, Cursor and any MCP client.
Free | Full | |
Logics | 50 | 600+ |
Categories | 8 core | 19 |
Runs | Locally | Hosted, nothing to install |
Updates | Occasional | Every new logic, for life |
Price | Free | €7 one-time |
Free categories: data persistence, networking & security, combat, monetization, UI/UX, NPC & AI, performance, libraries. The full edition adds movement, physics & VFX, world systems, game loops, tooling, audio, avatars, animation, input, social and live-ops.
Related MCP server: robloxstudio-mcp
git clone https://github.com/EL4CTEO/roblox-logics-mcp.git
cd roblox-logics-mcp
npm install
npm run buildRegister it with Claude Code:
claude mcp add roblox-logics -- node /absolute/path/to/roblox-logics-mcp/dist/index.jsOther clients (.mcp.json, Cursor, Claude Desktop):
{
"mcpServers": {
"roblox-logics": {
"command": "node",
"args": ["/absolute/path/to/roblox-logics-mcp/dist/index.js"]
}
}
}Tool | Use it to |
| Ask in plain words, get ranked one-line summaries. |
| Read one logic, or only the sections you need. |
| Find logics using a Luau API, e.g. |
| Pick up neighbouring parts of the same system. |
| See what is covered. |
| Browse one category. |
Search returns summaries only, so browsing is cheap. Your assistant only pays for the full write-up it picks.
Logics are markdown files at logics/<category>/<id>.md. See docs/AUTHORING.md for the format, then run npm run validate and npm run build:index.
Code: MIT. Content is community-sourced and summarized in our own words, with links to the originals. Always check the cited sources before shipping code.
Brickwise is an independent project, not affiliated with, endorsed by or sponsored by Roblox Corporation or the Luau team. Roblox and Luau are trademarks of Roblox Corporation.
Fetch the full write-up for one logic: the problem it solves, the numbered mechanism, illustrative Luau, pitfalls and source links. Call it only with an id returned by search_logics, list_logics or find_related — ids are not guessable. This is the expensive call: pass sections to pull just what you need (e.g. ['how-it-works'] to understand the mechanism, ['code'] to see the Luau).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Exact logic id, e.g. 'session-locked-player-data'. | |
| sections | No | Return only these sections instead of the whole document. Omit for everything. Cuts token cost substantially. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces the read-only, closed-world nature while adding value beyond them: the id-provenance requirement and the cost warning ('This is the expensive call'). It stops short of stating nothing about rate limits or partial-failure behavior for bad ids, so it is strong but not exhaustive.
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?
Three sentences, front-loaded with what is fetched, then the id precondition, then the cost/section optimization. Every clause carries actionable information with no filler.
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?
Even without an output schema, the description enumerates the returned document's parts and the section names, so an agent knows what it will receive. Combined with the id prerequisite and cost guidance, nothing needed to call this correctly is missing.
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 100%, giving a baseline of 3, and the description goes further by mapping section values to intent ('how-it-works' to understand the mechanism, 'code' to see the Luau) and by explaining why `sections` exists (token cost). The `id` provenance rule also adds meaning beyond the schema's format note.
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 ('Fetch') plus resource ('the full write-up for one logic') and enumerates the content returned: problem, numbered mechanism, Luau, pitfalls, source links. This clearly separates it from sibling listers/searchers like search_logics, list_logics and find_related.
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?
Explicitly states the precondition ('Call it only with an id returned by search_logics, list_logics or find_related — ids are not guessable') and names the alternative tools that produce valid ids. It also guides section-level usage ('pass `sections` to pull just what you need') with concrete selecting conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the categories of the Roblox logics knowledge base with a one-line blurb and how many logics each holds. Call this first when you do not know which area a problem belongs to, or to check whether the database covers a topic at all. Cheap (~500 tokens). Do NOT call it before every search — if you already have a concrete question, go straight to search_logics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=false, so safety and openness are covered. The description adds valuable behavioral context by disclosing the cost (~500 tokens) and the structured return shape (one-line blurb + logic count). It does not discuss pagination, caching, or error behavior, but for a cheap, read-only listing operation that is a minor 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 front-loaded with what it does, then gives concise usage guidance and a cost hint, and ends with an explicit exclusion. Every sentence earns its place, with no repetition or filler.
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 a zero-parameter, read-only listing tool with no output schema, the description covers everything an agent needs: what it returns (categories, blurbs, counts), when to call it, when not to call it, and the approximate cost. The absence of an output schema is compensated by the description explicitly stating the fields returned.
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?
There are zero parameters, so the baseline of 4 applies. The description does not need to explain parameter syntax, and it correctly focuses on what the tool returns instead. No meaningful parameter information is missing since the input schema is empty.
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 (Show) and resource (categories of the Roblox logics knowledge base), and immediately qualifies what is returned: a one-line blurb and a logic count. It distinguishes itself from sibling search_logics and list_logics by explicitly routing users to search_logics when they already have a concrete question.
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 explicit when-to-use guidance ('Call this first when you do not know which area a problem belongs to, or to check whether the database covers a topic at all') and a clear when-not-to-use rule ('Do NOT call it before every search — if you already have a concrete question, go straight to search_logics'). This is exactly the kind of constraint that prevents over-calling and directs to the right alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every logic in one category as id + title + summary. Use it to browse when the request is vague ('what data-persistence patterns do you have?') or after search_logics came back empty. For a specific question, search_logics is cheaper and better targeted.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category folder to list. See list_categories for the set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond that: the exact return shape (id + title + summary) and the cost/targeting tradeoff versus search_logics. It stops short of saying how large a category listing can be or whether results are truncated.
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?
Three sentences, each doing work: what it returns, when to use it, when not to. The return shape is front-loaded before the routing guidance.
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 no output schema, the description supplies the return shape; with a single fully-documented enum parameter, nothing more is needed on inputs; and the sibling routing is explicit. An agent can call this correctly without opening any other definition.
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 100% and the single enum parameter is fully documented, including a pointer to list_categories for the valid set. The description adds no syntax or semantic detail beyond what the schema already provides, 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 and resource ('List every logic in one category') and names the projected fields (id + title + summary), so an agent knows exactly what comes back. It is clearly distinguishable from search_logics, list_categories, and get_logic.
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?
Gives both directions: use for vague browsing requests or as a fallback when search_logics returns empty, and explicitly not for specific questions where search_logics is 'cheaper and better targeted'. The alternative and the selecting condition are both named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find logics whose example code uses a specific Luau symbol or Roblox API — 'UpdateAsync', 'BindToClose', 'ProcessReceipt', 'RaycastParams', 'task.defer'. Returns a short snippet with surrounding lines. This is a literal substring match over code blocks, not prose search: use search_logics for conceptual questions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results. | |
| symbol | Yes | Exact API name, method or identifier as it appears in code. Case-insensitive, no wildcards. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it discloses the matching semantics (literal substring, not semantic/prose) and the return shape ('a short snippet with surrounding lines'). It stops short of a 5 because it says nothing about result ordering, truncation, or what happens when limit is exceeded.
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?
Three sentences, front-loaded with the core purpose, then the examples, then the disambiguation rule. Zero filler and every clause carries information.
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?
There is no output schema, and the description compensates by stating the return format ('short snippet with surrounding lines'). Combined with the 100%-documented parameter schema and the annotations, an agent has everything needed to invoke this 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 100% — 'symbol' is fully documented (exact API name, case-insensitive, no wildcards) and 'limit' carries max 20/default 5. The example symbols in the description loosely illustrate the accepted value format, but add little beyond the schema, so the baseline of 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?
States a specific verb+resource ('Find logics whose example code uses a specific Luau symbol or Roblox API') and reinforces it with concrete example symbols like 'UpdateAsync' and 'task.defer'. It explicitly distinguishes itself from the sibling search_logics, so an agent can pick between them without opening either schema.
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?
Gives an explicit routing rule: literal substring match over code blocks, 'use search_logics for conceptual questions.' It also names what this tool is NOT for ('not prose search'), which is exactly the when-not guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Primary entry point. Search the knowledge base for how to build a Roblox system — 'stop exploiters firing remotes', 'save player data safely', 'melee hitbox that feels fair on high ping'. Returns metadata only (id, title, category, difficulty, summary) so browsing is cheap; follow up with get_logic(id) for the full write-up. Use search_code instead when you are looking for a specific Luau API such as UpdateAsync or BindToClose.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Require all of these tags (exact, kebab-case), e.g. ['datastore','autosave']. | |
| limit | No | Max results. Keep at 5 unless you are surveying a topic. | |
| query | Yes | Natural-language description of the problem or system. Plain words beat keywords. | |
| category | No | Restrict to one category. Omit unless you are certain — it can hide good cross-category matches. | |
| difficulty | No | Restrict to one difficulty level. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that by disclosing the return shape ('metadata only — id, title, category, difficulty, summary') and the rationale ('browsing is cheap'), which is important since no output schema exists. It stops short of describing pagination or ranking behavior, so a 4 rather than 5.
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?
Front-loads the role ('Primary entry point'), then examples, then return shape, then the alternative. Every sentence earns its place with no redundancy or filler.
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 search tool with no output schema, the description is complete: it covers the routing role, the cheap-metadata return contract, the follow-up path to get_logic, and the sibling alternative. An agent has everything needed to call it correctly and act on results.
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 every parameter including query, tags, limit, category, and difficulty is already documented with guidance. The description's example queries loosely illustrate the natural-language style of 'query' but add no new semantics beyond the schema, 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 and resource ('Search the knowledge base for how to build a Roblox system') with concrete example queries that pin down the intent. It distinguishes itself from siblings by naming both get_logic (for follow-up detail) and search_code (for specific Luau APIs).
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?
Explicitly positions itself as the 'Primary entry point', gives the condition for the alternative ('Use search_code instead when you are looking for a specific Luau API'), and prescribes the follow-up (get_logic(id)). When-to-use, when-to-use-something-else, and next-step are all covered.
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.
v1.0.0find_relatedget_logiclist_categorieslist_logicssearch_codesearch_logicsScored across 6 tools
Most tools are cleanly separated: get_logic fetches, search_code does literal code matching, and find_related traverses links. The only friction is the trio list_categories / list_logics / search_logics, which all touch browsing, but the descriptions explicitly state when to use each, largely resolving the overlap.
Every tool is snake_case with a predictable verb_noun shape (list_categories, search_logics, get_logic, search_code, find_related). No camelCase or vague single-word names, so the pattern is fully consistent.
Six tools is well-scoped for a read-only knowledge base: browse, search, code-search, fetch, and relate. Each tool earns its place with no redundant or filler operations.
The surface covers the full read lifecycle: discover categories, search concepts, search code, fetch full detail, and explore related entries. Minor gaps like tag-based filtering or citation export exist, but core workflows have no dead ends.
Curated knowledge API for AI agents - skill packs, semantic search, validated patterns.
Governed, auditable knowledge your team curates for its AI assistants, self-hostable
Shared knowledge base for AI agents. Semantic search across agents, no setup required — just a URL.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
