RedM / RDR3 docs MCP server: native lookups, semantic search, VORP, RSGCore, oxmysql.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.7/5 across 10 of 10 tools scored.
Each tool targets a distinct retrieval mode: structured asset lookup, script native resolution, exact token grep, semantic search, doc navigation, raw line access, and contribution. Descriptions explicitly cross-reference 'NOT for' cases, making misselection unlikely even where overlap exists.
Names mix verb-object (lookup_native, get_document, read_lines), object-verb (asset_lookup), bare verbs (browse), and descriptive phrases (semantic_search). The verb 'lookup' appears as both suffix and prefix, and 'get'/'read' are used interchangeably for retrieval, though all names are lowercase snake_case and readable.
10 tools is well-scoped for a documentation and reference server. Each tool fills a clear niche with no obvious bloat or redundancy, staying comfortably within the ideal 3-15 range.
The surface covers the full lifecycle of documentation access: orientation (list_namespaces), discovery (browse), exact and semantic search, native/asset lookup, full-content retrieval (get_document), raw line reading for large tables (read_lines), a calling-convention guide, and community contribution (share_finding). Known limitations in the data layer are addressed with companion tools.
asset_lookupLookup RedM game-data asset (ped/weapon/object/door/vehicle)AResolve a RedM game-data asset (ped model, weapon, object, door, vehicle) by exact name, 32-bit hash, or partial-name search. O(1) structured lookup against pre-parsed discoveries tables — replaces the common workflow of grepping a_c_bear_01 in peds_list.lua, then cross-referencing RELATIONSHIP/README.md for its relationship group. Returns: type, name, normalized hash (0x + 8 uppercase hex), source file + line, plus type-specific metadata (peds get variants + relationship, weapons get group, doors get coords + model_hash, objects get category/subcategory). Catalog ~22,500 entries (mostly objects). Typical latency p50 ~15ms, p95 ~65ms.
NOT for:
Script natives like SET_ENTITY_COORDS, GetPedHealth, or hashes from Citizen.InvokeNative(0x...) — use lookup_native. Native hashes are 64-bit (0x06843DA7060A026B); asset hashes are 32-bit (0xBCFD0E7F). Different namespaces, never collide.
Flag enums, settings, clipsets, scenario keys like CPED_CONFIG_FLAGS, MP_Style_Casual, mech_loco_m@, MAGGIE_SEAT_CHAIR_DESK_WRITING. Those live as tokens in lua source but not in this catalog. Use grep_docs.
Behavior queries ("which animal is the bear", "weapons in the lemat family") — use semantic_search.
Pass exactly ONE of name / hash / search. Optional type narrows to a category (useful when a fragment like "horse" hits both peds and vehicles). Note: type reflects the SOURCE FILE — the same asset name can exist under multiple types. e.g. mp006_p_mshine_int_door01x appears as type=object (1 row from object_list.lua) AND type=door (2 rows from doorhashes.lua, different door hashes for distinct in-world instances with coords). Pick type=door when you want lockable in-world doors with positions; type=object for the model itself.
Examples:
{name: "a_c_bear_01"} → exact ped lookup, returns variants=11 + relationship=REL_WILD_ANIMAL_PREDATOR.
{hash: "0xBCFD0E7F"} → resolves to ped a_c_bear_01 (omit 0x ok).
{search: "lemat", type: "weapon"} → substring match → weapon_revolver_lemat.
{search: "moonshine", type: "door"} → exact substring misses (no door name contains "moonshine"), fuzzy trigram fallback fires → mp006_p_mshine_int_door01x. Fuzzy mainly fires when type narrows out the exact-substring matches; without type, common terms find substring hits first and never reach fuzzy.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | No | Asset hash (32-bit jenkins) in HEX format, case-insensitive, `0x` prefix optional. Examples: `0xBCFD0E7F`, `bcfd0e7f`. Use when you have a hash from decompiled code or another table and need the canonical name + metadata. Decimal-formatted hashes (e.g. `1946191463`) are NOT accepted — convert to hex first (`(1946191463).toString(16)`). | |
| name | No | Exact asset name, case-insensitive. Examples: `a_c_bear_01`, `weapon_pistol_volcanic`, `p_safe01`, `armysupplywagon`. Use when you know the precise name. | |
| type | No | Filter results to one category. Useful when a name fragment matches multiple types (e.g. `horse` hits peds + vehicles). | |
| limit | No | Max matches to return. Default 5, max 50. Only applies to `search` — exact `name`/`hash` always return 0 or 1. | |
| search | No | Substring fragment within asset name, case-insensitive. Examples: `lemat`, `norfolk`, `volcanic`. Use when you remember part of the name. Algorithm: exact substring (ILIKE) first; if zero hits, falls back to pg_trgm `strict_word_similarity` ≥0.4 — catches abbreviation gaps like `moonshine`↔`_mshine_` when narrowed by `type` (without `type`, common terms find substring matches first and fuzzy never fires). `matchType` in the response tells you which path hit: `search` = exact substring, `fuzzy` = trigram. |
| Name | Required | Description |
|---|---|---|
| hint | Yes | |
| assets | Yes | |
| status | Yes | |
| hashFormat | Yes | |
| suggestions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state readOnlyHint=true and openWorldHint=false, but the description adds substantial behavioral detail: O(1) lookup, latency expectations, hash format (32-bit vs 64-bit), type reflects source file with multiple type rows possible, fuzzy trigram fallback threshold, matchType response, and limit semantics. No contradiction with annotations.
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 well-structured with a clear one-sentence summary, a 'NOT for' exclusion block, parameter-specific guidance, and labeled examples. It is long but every section carries essential information, is front-loaded, and avoids 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?
Given the tool's complexity (five parameters, multiple asset types, dual search modes, and an output schema), the description is remarkably complete. It covers exclusions, parameter selection, type semantics, fuzzy fallback triggers, and real-world examples. The expected output is described in sufficient detail even though an output schema exists.
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?
Although schema_description_coverage is 100%, the description adds critical semantic meaning beyond the schema: it explains that type reflects the source file and the same asset can appear under multiple types, describes how search alternates between substring and fuzzy trigram matching, and clarifies that limit only applies to search results. This substantially enriches the parameter understanding.
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 opens with a precise verb 'resolve' and specifies the exact resource (RedM game-data asset) and categories (ped, weapon, object, door, vehicle). It clearly distinguishes from sibling tools via the 'NOT for' section, explicitly naming lookup_native, grep_docs, and semantic_search as alternatives for different use cases.
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?
Provides explicit 'when to use' and 'when not to use' guidance, including named alternative tools. It prescribes exactly one of name/hash/search, explains when to use the type filter, and gives concrete examples for each lookup mode. The fuzzy fallback behavior is also clearly described with a specific example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
browseBrowse RedM doc pathsAEnumerate doc paths in a category/namespace. Use to discover what exists before calling get_document or a targeted grep_docs. NOT a content search — use semantic_search for behavior/concept lookups or grep_docs for token lookups. Returns {path, title, chunks}[].
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| namespace | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond the annotation: it returns a specific shape ({path, title, chunks}[]) and clarifies that it is enumeration, not content search. It does not contradict the annotations. Minor gap: it doesn't mention whether chunks are full content or summaries, but the read-only nature is clear.
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 three sentences with no wasted words. It front-loads the primary action, provides usage timing, excludes confusing alternative uses, and gives the return shape. Every 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 two-parameter read-only discovery tool with no output schema, the description is mostly complete: it states purpose, usage timing, exclusions, and return format. The only notable incompleteness is the ambiguous namespace parameter semantics, which prevents a perfect score. Overall, an agent has enough context to use the tool correctly in most cases.
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%, so the description must carry the burden of explaining parameters. The description only says 'in a category/namespace,' which mentions both parameter names but does not explain what a namespace is, how it interacts with category, or what happens when neither is provided. The enum for category is self-explanatory, but the namespace string remains ambiguous. This is a significant gap given the lack of schema descriptions.
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 opens with a specific verb and resource: 'Enumerate doc paths in a category/namespace.' It clearly distinguishes itself from content-search siblings by explicitly saying 'NOT a content search' and naming semantic_search and grep_docs as alternatives. This makes the tool's purpose 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?
The description explicitly states when to use this tool: 'Use to discover what exists before calling get_document or a targeted grep_docs.' It also provides clear exclusion guidance: 'NOT a content search — use semantic_search for behavior/concept lookups or grep_docs for token lookups.' This is model guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_documentGet full RedM docAFetch full markdown of a doc by path (as returned by browse, semantic_search, or grep_docs). Use to retrieve full content after a search snippet looks promising. Pass heading (full breadcrumb like Character Management > Inventory Management, or just the leaf — case-insensitive, fuzzy) to fetch only that section. Deep-heading matches auto-prepend the H2 parent's intro for context. For individual script natives prefer lookup_native. The largest rdr3_discoveries lua data tables are keyed catalogs: call with no heading to list their top-level keys, then pass a key as heading to fetch that one entry; use grep_docs to search values inside. For code symbols (addItem) use grep_docs. Community findings use learning:N paths, not learnings/<slug>.md. On 404 returns available headings + cross-file hints.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Doc path. Two valid shapes: (a) `<category>/<file>.md` for docs, e.g. `vorp/vorp_core_docs.md`; (b) `learning:<id>` for community findings, e.g. `learning:11`. Use the path returned by `browse`/`semantic_search`/`grep_docs` verbatim — do not invent `learnings/<slug>.md`. | |
| heading | No | Optional prose heading from the doc, e.g. `Add Item to User` or `Character Management > Inventory Management`. Case-insensitive, fuzzy match on the leaf (text after the final `>`). NOT for code symbols — `addItem`, `getPlayerPed` etc. won't match; use `grep_docs` for those. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behaviors not covered by annotations: deep-heading matches auto-prepend H2 parent intro, calling with no `heading` on data tables lists top-level keys, and 404 responses include available headings + cross-file hints. It also clarifies path validation (learning:N vs learnings/<slug>.md). These are significant behavioral details.
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 dense and front-loaded with the core action, then systematically covers usage scenarios, exclusions, and special cases. It is somewhat long, but every sentence contributes crucial context for a tool with many nuanced behaviors, making it appropriately structured.
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 states the return (markdown) and error behavior (404 headings/hints). It also addresses special cases (data tables, community findings) and explains how to use headings for sections. This is a complete reference for the tool's complexity.
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?
Although the schema has 100% parameter coverage, the description enriches both parameters. It explains that `path` should be used verbatim from other tools, and `heading` supports breadcrumbs, leaf-only, case-insensitive fuzzy matching, plus special behavior for keyed catalogs. This goes far beyond the schema's basic descriptions.
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 opens with a specific verb and resource: 'Fetch full markdown of a doc by `path`'. It specifies the document types and return format, and distinguishes itself from siblings like `lookup_native` and `grep_docs` by stating what it is NOT for. This provides unambiguous purpose.
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?
Explicit 'Use to retrieve full content after a search snippet looks promising' gives a clear trigger. It repeatedly states when to prefer alternatives ('For individual script natives prefer `lookup_native`', 'For code symbols (`addItem`) use `grep_docs`') and even explains special handling for data tables and community findings. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_invoke_guideGet native invocation guide for a languageALoad the calling-convention reference for RedM/RDR3 natives in js or lua. Call ONCE per session before writing native-calling code — every native doc page only shows Lua examples, so JS/TS authors need this to translate correctly. Covers result modifiers (Citizen.resultAsInteger/Float/String/Vector), Citizen.invokeNative vs invokeNativeByHash, type mapping, pointer-arg gotchas, worked examples. Cheap, no embedding.
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | Target language: 'js' or 'lua' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: 'Cheap, no embedding' and 'Call ONCE per session' (a usage constraint). It does not contradict annotations and provides extra context beyond the structured fields.
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 dense paragraph, front-loaded with the core action, followed by usage context, content list, and cost/behavior notes. Every sentence carries information with no redundancy or fluff.
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 one enum parameter, read-only annotation, and no output schema, the description covers purpose, when to use, content, and cost. It is complete for the tool's complexity and leaves no critical gaps.
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 input schema already contains 100% parameter coverage with an enum for language and a description. The tool description repeats 'js' or 'lua' but does not add new semantic detail beyond the schema, so it meets the baseline but does not elevate it.
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 loads a 'calling-convention reference' for RedM/RDR3 natives in js or lua, which is a specific verb+resource. It distinguishes itself from sibling tools like lookup_native and get_document by focusing on the invocation guide rather than general documentation.
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 ONCE per session before writing native-calling code' and explains why every native doc page only shows Lua examples. However, it does not name specific alternative tools or provide when-not-to-use scenarios, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
grep_docsLiteral/regex grep over raw doc filesAFind an EXACT literal token in raw doc files (markdown + lua). Use for specific weapon/ped/animation/prop/interior/zone names (weapon_pistol_volcanic, a_c_bear_01, p_campfire01x), known hashes (0x020D13FF), walkstyles/clipsets (MP_Style_Casual, mech_loco_m@), or any string you'd grep for. NOT for behavior/concept queries (use semantic_search) or script-native hash/name lookup (use lookup_native). REQUIRED for tokens inside the largest rdr3_discoveries data tables (audio_banks, ingameanims_list, cloth_drawable, cloth_hash_names, object_list, megadictanims, entity_extensions, imaps_with_coords, propsets_list, vehicle_bones) — only preview-indexed for embeddings, so semantic_search will NOT find tokens in them. Optional: contextBefore/contextAfter for ±N surrounding lines (saves a follow-up get_document call); filesOnly: true to get paths only (cheap exploration); multiline: true for cross-line patterns ((?s)foo.*bar). Pattern uses Rust regex syntax (rg engine). PREFER one targeted call over giant a|b|c|d|e alternations — split into separate calls; alternations rarely improve recall and bloat the regex automaton. Returns matched lines with path + line number. Long matched lines are windowed ±60 chars around the match (…); to read around a hit, use read_lines({path, start}) for the preview-only mega-tables listed above (get_document holds only their ~80-line head), or get_document({path}) for ordinary docs. If you are retrying after a previous pattern returned no matches, populate prior_attempt so the server can record what didn't work and steer alternative spellings.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| pattern | Yes | Rust regex pattern (ripgrep engine). Case-insensitive by default. Prefer narrow, single-token patterns over kitchen-sink alternations. | |
| category | No | Limit to a doc category (e.g. discoveries, natives). | |
| filesOnly | No | Return only the list of matching paths (no per-line matches). Cheap for exploration before zoom-in. | |
| multiline | No | Allow `.` to match newlines and patterns to span lines (rg -U --multiline-dotall). Use for `(?s)foo.*bar` style. | |
| contextAfter | No | Include N lines after each match (rg -A). | |
| contextBefore | No | Include N lines before each match (rg -B). Saves follow-up get_document calls when you need surrounding context. | |
| pathSubstring | No | Substring filter on relative doc path, e.g. 'weapons' or 'clothes/cloth_hash_names'. | |
| prior_attempt | No | Populate ONLY when retrying after a previous grep_docs call returned no matches. Skip on first attempts. | |
| caseInsensitive | No | Default true. Set false for case-sensitive match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, but the description adds substantial behavioral details: Rust regex engine, case-insensitive default, ±60 character windowing on long matches, and the special limitation that preview-only mega-tables require read_lines instead of get_document. These go well beyond what annotations convey, with no contradictions.
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 long but every section earns its place: purpose, use cases, exclusions, mega-table behavior, parameter tips, regex syntax, and retry protocol. It is front-loaded with the core verb and resource, and the paragraphing keeps it scannable, though it could be tightened slightly.
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 10-parameter tool with no output schema, the description covers return format (matched lines with path and line number), special constraints for mega-tables, retry semantics, and how to read around hits. It leaves minimal ambiguity and pairs well with the sibling tool descriptions.
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?
Despite 90% schema coverage, the description enriches parameter meaning: contextBefore/contextAfter saves a follow-up get_document call, filesOnly is described as cheap exploration, multiline enables (?s) patterns, and prior_attempt is populated only on retries. This adds functional context the schema does not provide.
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 opens with 'Find an EXACT literal token in raw doc files (markdown + lua)', which identifies the verb, resource, and scope precisely. It also distinguishes itself from siblings by naming semantic_search for concept queries and lookup_native for hash/name lookup, so the tool's unique 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?
It provides an explicit 'Use for' list (weapon/ped/animation names, known hashes, walkstyles) and an explicit 'NOT for' list with named alternatives. It also highlights REQUIRED usage for specific mega-tables and advises against large alternations, giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_namespacesList RedM doc namespacesAOrient yourself: list available doc categories and their namespaces. Use once at session start (or when unsure) before applying a category= / namespace= filter to browse / semantic_search. NOT a content search. Categories: natives (PLAYER, ENTITY, VEHICLE, …), vorp, rsgcore, oxmysql, discoveries (AI, weapons, peds, animations, clothes, objects, …), jo_libs (menu, notification, callback, framework-bridge, …, dev_resources, redm_scripts), guides, learnings.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
| Name | Required | Description |
|---|---|---|
| categories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already provided, the description adds meaningful context: it is an orientation-only tool, not a content search, and it enumerates the categories. It does not detail the exact return shape, but the presence of an output schema mitigates that 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 a one-line purpose, then gives a tight usage rule, an exclusion, and a clear category list. Every sentence adds value, and the structure is scannable without being bloated.
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 tool's simple input (one optional param), read-only annotation, and existing output schema, the description covers purpose, when/how to use, category options, and relation to sibling tools. Nothing important is missing for a tool of this complexity.
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 schema has one optional param with an enum but zero description coverage; the description fully compensates by listing and explaining the category values (natives, vorp, rsgcore, etc.) and connecting them to content areas. This goes well beyond raw enum labels.
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 ('list') and resource ('available doc categories and their namespaces'), clearly distinguishing itself from content-search tools by stating 'NOT a content search' and naming related tools like 'browse' / 'semantic_search'. This makes the tool's role 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?
It explicitly states when to use the tool ('Use once at session start (or when unsure)') and frames it as a prerequisite before applying category or namespace filters to other tools. It also gives an exclusion ('NOT a content search'), which is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_nativeLookup RedM native by hash or nameAResolve a RedM/RDR3 SCRIPT native by hash or name — O(1), exact. Use whenever you see Citizen.InvokeNative(0x...), Citizen.invokeNative('0x...'), GetHashKey('NAME'), or a SCREAMING_SNAKE_CASE native name (e.g. SET_ENTITY_COORDS, GetPedHealth) in Lua/JS/TS. NOT for game-data hashes (weapon/ped/animation names) — use grep_docs. Pass hash (0x… optional, case-insensitive) or name (exact first, ILIKE substring fallback). Returns name, hash, namespace, return type, params, description, full content, plus findings[] — community gotchas linked to that native. Inspect findings[].id and call get_document({path: 'learning:<id>'}) for full body. Also returns refDocs[] — enum/flag value tables for that native (the constants to pass for params like flagId/attributeIndex/eventType). When refDocs[].content is set, it's the inline enum table — use those values directly. When content is null but refDocs[].fetch is present, the table was too large to inline — run that exact call (e.g. get_document({ path: "refdoc:eEventType" })) to get the full table; refDocs[].preview shows the first lines. github entries (no fetch) are url-only.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | No | Native hash, e.g. 0x09C28F828EE674FA (case-insensitive, 0x optional) | |
| name | No | Native name, e.g. CAN_PLAYER_START_MISSION. Substring match if no exact hit. | |
| limit | No | ||
| namespace | No | Restrict to a namespace, e.g. PLAYER, ENTITY. Only used with `name`. |
| Name | Required | Description |
|---|---|---|
| hint | Yes | |
| status | Yes | |
| natives | Yes | |
| suggestions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark readOnlyHint=true, but the description adds rich behavioral detail: exact-first then ILIKE substring fallback, return structure including findings and refDocs, and how to handle inline vs fetch-based enum tables. No contradiction with annotations.
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 long but dense with actionable detail; every major aspect (use case, return, refDocs handling) is covered without fluff. It could be slightly trimmed, but its length is justified by the tool's complexity.
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 no required params and a rich output, the description covers input ambiguity, output interpretation, and integration with get_document via findings ids and refDoc fetch paths. Combined with annotations and output schema, an agent has all needed context.
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 covers 75% of parameters, but description adds critical semantics: hash is case-insensitive, name uses exact-first with ILIKE fallback, and namespace is restricted to name queries. The limit parameter is only covered by schema, though its numeric min/max/default suffice.
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 exactly what it does: resolves a RedM/RDR3 SCRIPT native by hash or name with O(1) exact match. Clearly differentiates from game-data hash lookups by explicitly pointing to grep_docs, making its scope 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?
Provides explicit when-to-use triggers (Citizen.InvokeNative calls, GetHashKey, SCREAMING_SNAKE_CASE names) and a clear negative case (weapon/ped/animation hashes → grep_docs). Names the alternative tool and describes fallback behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_linesRead an exact line range from a raw doc fileARead an exact line range from a raw doc file by absolute line number — the windowed-read companion to grep_docs. When grep_docs returns a hit at path:line inside a large file, call read_lines({ path, start, end }) to pull the surrounding block. This is the ONLY way to read around a hit in the largest rdr3_discoveries data tables (audio_banks, ingameanims_list, ptfx, soundsets, imaps_with_coords, megadictanims, etc.): their full bodies are NOT in the vector/heading index (only an ~80-line preview is), so semantic_search can't reach them and get_document resolves real section headings only — NOT synthetic lines N-M offsets. start/end are 1-based and inclusive; omit end for a 50-line window; one call returns at most 400 lines (narrow the range for more). For prose .md docs prefer get_document with a heading; to search values use grep_docs; for individual script natives use lookup_native.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Last line to return (1-based, inclusive). Omit for a 50-line window from `start`. Spans over 400 lines are capped. | |
| path | Yes | Doc path exactly as returned by `grep_docs` / `browse` / `semantic_search`, e.g. `discoveries/audio/audio_banks/audio_banks.lua`. Do not invent paths. | |
| start | Yes | First line to return (1-based, inclusive). Use the line number from a `grep_docs` hit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits beyond the readOnlyHint annotation: 1-based inclusive line ranges, optional end with 50-line default, 400-line max, and why full bodies are not accessible via semantic_search or get_document. This provides crucial context for understanding tool limitations and expected behavior.
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 long but every sentence serves a purpose, covering purpose, alternatives, limitations, and parameter behavior. It is front-loaded with the main action and remains well-structured, though it could benefit from breaking into shorter sentences for readability.
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 tool's complexity and the rich schema/annotations, the description is exceptionally complete: it explains when to use it, how it interacts with sibling tools, exact line semantics, caching limitations, and alternative tools. No output schema is needed, and the description fully compensates.
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 input schema already documents all parameters with full descriptions (100% coverage), so the baseline is 3. The description adds extra value by explaining the intended source of each parameter (e.g., path from grep_docs/browse/semantic_search, start from a grep_docs hit) and the inclusive/windowing semantics, which the schema only partially conveys.
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 purpose: 'Read an exact line range from a raw doc file by absolute line number'. It also distinguishes itself from siblings by being the 'windowed-read companion to grep_docs' and explaining how it differs from semantic_search and get_document.
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?
Explicit usage guidance: call read_lines after a grep_docs hit, and it is the ONLY way to read around hits in large data tables. It also gives clear alternatives: use get_document for prose .md docs, grep_docs for searching values, and lookup_native for natives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
semantic_searchHybrid search RedM docs (semantic + lexical)ASearch RedM/RDR3 docs by behavior, concept, OR exact token. Use when you don't have a specific native hash/name (use lookup_native) and the term isn't a known asset name in a large data table (use grep_docs). Hybrid mode (default) handles 'how do I X' queries ('teleport player', 'spawn vehicle', 'inventory add item') AND tokens ('addItem', 'weapon_pistol_volcanic', 'CPED_CONFIG_FLAG_') — fused via RRF over vector + BM25. Returns ranked snippets (path, breadcrumb, heading, snippet, score). Call get_document({path, heading}) for full chunk content. mode=semantic for pure vector; mode=lexical for pure BM25. Filter via category=vorp|rsgcore|oxmysql|natives|discoveries|jo_libs|learnings or namespace. Community findings merged by default; category=learnings returns only findings. If you are retrying after a previous call returned no useful results, populate prior_attempt so the server can surface alternative wordings and learn what's missing from the docs.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Retrieval mode. Default hybrid (recommended). | |
| limit | No | How many ranked snippets to return. Default 20 (Anthropic contextual-retrieval research: top-20 outperforms top-5/10 before reranking). | |
| query | Yes | Natural language or token query | |
| category | No | Limit to one doc category | |
| namespace | No | Limit to a native namespace, e.g. PLAYER, ENTITY | |
| prior_attempt | No | Populate ONLY when retrying after a previous semantic_search call returned no useful results. Skip on first attempts. | |
| responseFormat | No | `concise` (default): 400-char snippet per hit — cheap, browse-style. `detailed`: full chunk content — use when you need an answer in one round-trip and want to skip the `get_document` follow-up. | concise |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals rich behavioral details: hybrid mode with RRF fusion, output snippet structure (path, breadcrumb, heading, snippet, score), community findings merging, category=learnings behavior, and the retry mechanism with prior_attempt. No contradiction with annotations.
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?
Every sentence earns its place: purpose, alternatives, hybrid behavior, output format, follow-up, mode options, filtering, community findings, retry guidance. It is dense but not wasteful, front-loading the main purpose and then layering necessary details for a complex 7-parameter tool.
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 tool has 7 parameters, nested objects, no output schema. The description compensates by specifying the return structure (ranked snippets with fields), covering edge cases (retry, learnings, categories), and guiding subsequent get_document calls. It is complete enough for an agent to operate effectively without additional clarification.
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%, so baseline is 3. The description adds value by explaining the semantics of mode (semantic vs lexical vs hybrid) and giving concrete query examples that illustrate parameter usage. It also clarifies prior_attempt's purpose beyond the schema description, earning a 4.
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 starts with a specific verb and resource: 'Search RedM/RDR3 docs by behavior, concept, OR exact token.' It clearly distinguishes from siblings by explicitly stating when to use lookup_native and grep_docs instead, making the purpose 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?
Provides explicit when-to-use guidance: 'Use when you don't have a specific native hash/name (use lookup_native) and the term isn't a known asset name in a large data table (use grep_docs).' It also directs users to get_document for full content and describes the prior_attempt retry workflow, covering both use cases and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.