roblox-logics-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_categoriesA | 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. |
| search_logicsA | 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. |
| list_logicsA | 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. |
| get_logicA | 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 |
| search_codeA | 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. |
| find_relatedA | Given a logic id, return logics it explicitly links to plus ones sharing distinctive tags or services (weighted by rarity). Use it after get_logic to pick up the neighbouring pieces of a system (a DataStore logic pointing at retry/backoff and autosave). Not a search tool — for a new question use search_logics. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.