redm-mcp
Server Details
RedM / RDR3 docs MCP server: native lookups, semantic search, VORP, RSGCore, oxmysql.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Cmoen11/redm-mcp-public
- GitHub Stars
- 0
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.
Tool Definition Quality
Average 4.6/5 across 10 of 10 tools scored.
Each tool has a clearly distinct purpose: asset_lookup for game data, browse/get_document for doc navigation, grep_docs for exact tokens vs semantic_search for concepts, lookup_native for script natives, etc. No overlap in scope.
All tools use consistent snake_case naming with a verb_noun pattern (e.g., list_namespaces, lookup_native, share_finding). No mixing of styles.
10 tools is well-scoped for the server's purpose of RedM documentation and game data lookup. Each tool covers a distinct operation without redundancy.
The tool set covers the full lifecycle of doc interaction: orientation (list_namespaces), search (semantic_search, grep_docs), retrieval (get_document, browse, read_lines), specific lookups (asset_lookup, lookup_native), and contribution (share_finding). No obvious gaps.
Available Tools
10 toolsasset_lookupLookup RedM game-data asset (ped/weapon/object/door/vehicle)AInspect
Resolve 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 fromCitizen.InvokeNative(0x...)— uselookup_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. Usegrep_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 peda_c_bear_01(omit0xok).{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 whentypenarrows out the exact-substring matches; withouttype, 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden, disclosing return structure, catalog size, latency, search algorithm (substring then fuzzy trigram), type behavior, and edge cases like limit applicability.
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-organized with sections for purpose, exclusions, parameters, and examples, but is somewhat verbose; minor condensation could improve conciseness without losing 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?
Despite no output schema, the description fully explains return values, type-specific metadata, and provides examples for each parameter and edge cases, making it complete for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even with 100% schema coverage, the description adds substantial value with use-case-specific guidance, algorithm details, and examples for each parameter, going far beyond the schema alone.
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 resolves RedM game-data assets by name, hash, or search, and explicitly distinguishes from siblings like lookup_native, grep_docs, and semantic_search, making its purpose 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 guidance with exclusion criteria (not for script natives, flag enums, behavior queries) and names alternative tools for those cases. Also explains when to use the type parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
browseBrowse RedM doc pathsAInspect
Enumerate 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Discloses return format as {path, title, chunks}[]. Lacks details on pagination or ordering, but for a browse tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loads purpose and usage guidelines 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?
No output schema, but description explicitly states return format. Covers use case and alternatives. Complete for a discovery tool given sibling 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 coverage is 0%. Description mentions 'category/namespace' linking to parameters but does not explain each parameter's meaning or default behavior. Provides basic context that they are used together.
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?
Clearly states verb (enumerate) and resource (doc paths). Distinguishes from siblings by specifying that it's for discovery before get_document or grep_docs, not for content search.
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 provides when to use (discover before fetching) and when not (for content or token lookups, redirecting to semantic_search and grep_docs).
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 docAInspect
Fetch 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly explains behavior: heading filtering, auto-prepend of H2 parent, behavior for large tables (listing keys), 404 response with available headings, and cross-file hints.
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?
Slightly verbose but every sentence adds value; front-loaded with main purpose. Could be trimmed slightly but still well-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?
For a tool with 2 params, no output schema, and no annotations, the description covers return behavior, edge cases (404), and complex scenarios (large tables) comprehensively.
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% but description adds significant extra meaning: path shapes, heading fuzzy match, deep-heading context, and special table behavior.
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 fetches full markdown of a doc by path, referencing how paths are obtained from sibling tools, which distinguishes it from alternatives.
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 says when to use (after search snippet looks promising) and when not (for script natives use lookup_native, for code symbols use grep_docs), providing clear 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 languageAInspect
Load 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' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses it is 'Cheap, no embedding' and lists contents. It implies read-only behavior, though it does not explicitly state no side effects.
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?
Four sentences with no wasted words. Front-loaded with purpose, then usage, contents, and cost. Every sentence adds value.
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 single-parameter tool with no output schema, the description explains what the guide covers (result modifiers, invokeNative vs hash, etc.) and when to use it. Lacks output format but is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter fully described. The description adds context about language choice but no new syntactic or semantic details beyond 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 clearly states 'Load the calling-convention reference for RedM/RDR3 natives' with specific verb and resource. It distinguishes from siblings like 'lookup_native' and 'get_document' by focusing on the invocation guide for JS and Lua.
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 says 'Call ONCE per session before writing native-calling code' and explains why JS/TS authors need it. However, it doesn't explicitly state when not to use it (e.g., for Lua-only users).
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 filesAInspect
Find 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: returns matched lines with path/line, windowing for long lines, requirement for preview tables, retry mechanism, regex syntax, and default case-insensitivity.
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?
Well-structured with clear headings and emphasis, but slightly verbose; all sentences add value, so overall effective.
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 10 params and no output schema, the description is very complete, covering return format, edge cases, retry guidance, and differentiating from siblings.
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 90%, so baseline 3; description adds meaningful context beyond schema: usage examples, strategy for patterns, explanation of prior_attempt, and tips for multiline.
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 finds exact literal tokens in raw doc files, specifies token types with examples, and distinguishes it from semantic_search and lookup_native.
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 tells when to use (specific tokens, required for certain data tables) and when not to (concept queries, hash/name lookup), and advises on pattern strategy (prefer targeted calls, avoid alternations).
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 namespacesAInspect
Orient 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool is a harmless orientation action (read-only) and clarifies it is not a content search, but does not detail the output format or any potential side effects, though none are expected.
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 highly concise yet informative, with a front-loaded purpose statement and essential usage guidance, including a comprehensive list of categories, without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, and parameter values well. However, without an output schema, a brief note on the output format (e.g., list of namespaces) would enhance completeness, though the implication is clear.
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 description enriches the input schema by listing and explaining the enum values for the category parameter, including subcategories (e.g., 'natives (PLAYER, ENTITY, VEHICLE, …)'), which adds significant meaning beyond 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 clearly states the tool lists available doc categories and their namespaces, distinguishing it from sibling tools like browse and semantic_search by explicitly noting it is not a content search.
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 advises to use the tool at session start or when unsure before applying a category/namespace filter to browse or semantic_search, providing explicit guidance on when to use and context for alternatives.
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 nameAInspect
Resolve 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`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains O(1) exact, return fields (findings, refDocs) and how to use them. Missing rate limits or error handling, but otherwise transparent.
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?
Single long paragraph with good front-loading of purpose, but contains detailed refDocs handling that could be more concise. Acceptable given 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?
Given no output schema or annotations, the description covers return types, findings, refDocs, and how to fetch large refDocs. Lacks mention of what happens on no match or errors, but fairly complete.
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?
Adds meaning beyond schema: explains hash vs name, case-insensitivity, substring fallback, and that namespace only works with name. Limit parameter is not mentioned in description but schema covers it. With 75% schema coverage, description adds value.
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 it resolves a RedM/RDR3 native by hash or name, specifying O(1) exact lookup. It distinguishes from sibling grep_docs which is for game-data hashes.
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 tells when to use: when encountering Citizen.InvokeNative or SCREAMING_SNAKE_CASE names. Also tells when not to use: for game-data hashes, and directs to grep_docs.
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 fileAInspect
Read 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses behavioral traits: 1-based inclusive line numbers, optional end defaults to 50-line window, max 400 lines, and the tool's role as a windowed reader for raw files. It does not explicitly state read-only behavior but is strongly implied.
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 somewhat long but every sentence adds value. It front-loads the core purpose and uses clear structure. Could be slightly more concise but remains efficient.
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 3-parameter tool with no output schema and no annotations, the description covers purpose, usage context, parameter semantics, limitations (400 lines), and alternatives. It does not describe the output format, but the tool is simple enough that the input schema and description suffice.
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 significant extra meaning: path must be exact from grep_docs/browse/semantic_search, start line from grep_docs hit, end omit for 50-line window capped at 400 lines. This goes 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 clearly states 'Read an exact line range from a raw doc file by absolute line number' and distinguishes it from siblings like grep_docs, get_document, and lookup_native. It explicitly positions itself as the windowed-read companion to grep_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 description provides explicit when-to-use (after grep_docs hit), when-not-to-use (prose .md files prefer get_document, search values use grep_docs, natives use lookup_native), and context (only way to read around hits in large data tables).
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)AInspect
Search 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes hybrid mode with RRF, default mode, return format (ranked snippets with fields), category filtering, namespace filtering, and retry behavior. No annotations exist, so description fully handles transparency.
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?
Description is detailed but well-structured, starting with purpose, then usage guidance, mode details, and parameter explanations. Slightly verbose for the level of detail needed, but not excessive.
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?
Despite no output schema, description explains return format. All 7 parameters are covered, including nested prior_attempt. The tool's complexity is fully addressed with no 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?
Schema has 100% coverage, but description adds significant context beyond schema, e.g., explaining mode differences, prior_attempt usage, responseFormat options, and category semantics (community findings vs learnings).
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 searches RedM/RDR3 docs by behavior, concept, or exact token. It distinguishes from siblings like lookup_native and grep_docs, providing specific 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?
Explicitly states when to use this tool vs alternatives (e.g., 'Use when you don't have a specific native hash/name...'). Also provides guidance for retrying with prior_attempt parameter.
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.
Discussions
No comments yet. Be the first to start the discussion!