RedM Mcp
Server Details
RedM (Red Dead Redemption 2 multiplayer) / RDR3 modding. Hosted HTTP endpo
int: native lookups (hash ↔ name), semantic search over framework docs (VORP, RSGCore, oxmysql), and grep over rdr3_discoveries community data tables (peds, weapons,
animations, AI flags, props). No install, no auth.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.7/5 across 10 of 10 tools scored.
Each tool has a clearly distinct purpose: asset_lookup for game assets, lookup_native for script natives, grep_docs for exact token search, semantic_search for concept search, browse/get_document for docs, list_namespaces for categories, read_lines for raw file content, and share_finding for contributions. Descriptions explicitly state when NOT to use each, eliminating ambiguity.
Most tools follow a consistent verb_noun pattern with underscore_case (e.g., asset_lookup, get_document, grep_docs). 'browse' is a single verb without a noun, slightly deviating from the pattern. Overall, the naming is predictable and readable.
With 10 tools, the set is well-scoped for a RedM development assistant. Each tool covers a distinct need (asset lookup, native lookup, documentation search, etc.) without redundancy or excessive specialization.
The tool surface covers core workflows for RedM modding: asset lookup, native resolution, documentation browsing/searching, and community contribution. Minor gaps exist (e.g., no direct code execution or validation), but the set aligns well with the stated purpose.
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?
No annotations are provided, but the description compensates fully. It details O(1) lookup, latency stats, catalog size, search algorithm (substring then fuzzy), and return fields. No omissions for a read-only lookup tool.
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 longer but well-organized. It front-loads the core purpose, uses clear sections (NOT for, parameter guidance), and avoids redundant sentences. Minor length is justified by 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?
Covers all aspects: purpose, parameters in detail, behavior (search algorithm, latency), return fields, and edge cases (multiple types, fuzzy fallback). No gaps given the tool's complexity and lack of output schema.
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%, yet the description adds value: explains usage context for each parameter (e.g., hash format with conversion hint), search algorithm behavior, and type caveats. Exceeds schema information.
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 RedM game-data assets by name, hash, or partial search. It distinguishes from siblings like lookup_native and grep_docs, making 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?
Explicitly lists what the tool is not for, with specific alternatives (lookup_native, grep_docs, semantic_search). It also explains when to use each parameter and the optional type filter.
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 exist, so the description must carry the full burden. It discloses that the tool returns an array of objects with path, title, and chunks, implying a read-only listing operation. While not exhaustive (e.g., no mention of permissions or limitations), it is sufficient for an enumeration tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the purpose and providing actionable guidance without any redundant or extraneous 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?
Given the low complexity of the tool (enumeration with only two parameters), no annotations, and no output schema, the description adequately covers when, how, and what the tool returns. It also references sibling tools appropriately.
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%, and the description does not explain the individual parameters (category, namespace). The category enum provides some context, but namespace is left undefined. The description fails to add meaning beyond the bare 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 'Enumerate doc paths in a category/namespace', providing a specific verb and resource. It distinguishes itself from siblings by explicitly stating when to use browse versus get_document, grep_docs, or semantic_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 provides explicit guidance on when to use the tool ('Use to discover what exists before calling get_document or a targeted grep_docs') and when not to ('NOT a content search — use semantic_search for behavior/concept lookups or grep_docs for token lookups').
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?
With no annotations, the description fully discloses behavior: returns full markdown, heading parameter fetches sections, deep-heading prepends H2 intro, data table listing on no heading, and 404 returns headings plus hints. 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 dense but efficient; every sentence adds value. It front-loads the main functionality. Slightly verbose with examples, but appropriate for 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?
Given no output schema, the description adequately covers return values (full markdown, or available headings on 404) and special behaviors. It addresses all relevant aspects for effective tool invocation.
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 coverage is 100%, the description adds substantial value: clarifies path formats, heading matching rules (case-insensitive, fuzzy, not for code symbols), and special data table key listing behavior. Goes well 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 fetches full markdown of a doc by path. It distinguishes itself from siblings by mentioning when to use lookup_native for natives and grep_docs for code symbols, ensuring the agent understands the tool's specific role.
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 ('after a search snippet looks promising'), when not to use (for natives or code symbols), and names alternatives (lookup_native, grep_docs). Also provides guidance for data tables and community findings.
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?
With no annotations, the description carries full burden. It discloses the tool is cheap, has no embedding, and should be called once. This gives reasonable behavioral insight, though it could mention idempotency or caching.
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 concise: five sentences covering purpose, usage, rationale, content, and cost. No redundancy, front-loaded with key action, 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?
Given the simple single-parameter tool with no output schema, the description fully covers when to use, what it includes, and why. Complete 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?
Schema coverage is 100% (enum for language). The description adds motivation (JS/TS authors need this) but does not add parameter semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads the calling-convention reference for RedM/RDR3 natives in js or lua, distinguishing it from sibling tools like get_document or lookup_native which operate on different content.
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 advises to call once per session before writing code and explains why it's needed (only Lua examples elsewhere), providing clear usage context. It does not enumerate alternatives but the guidance is sufficient.
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 covers behavioral traits: default case-insensitivity, Rust regex, windowed output, retry mechanism via prior_attempt, and recommendations for context retrieval.
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?
Long but front-loaded with core purpose, logically organized from use case to parameters to return info and retry guidance; 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?
Thorough for 10 parameters with no output schema or annotations: explains return format, windowing, context retrieval alternatives, and retry handling.
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, description adds significant nuance: pattern narrowing, filesOnly for cheap exploration, context lines to avoid extra calls, multiline for cross-line patterns, prior_attempt for retries, and caseInsensitive default.
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 finds exact literal tokens in raw doc files, provides concrete examples (weapon_ped_...), and distinguishes from siblings like 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 states when to use (specific tokens), when not to (behavior/concept queries, script-native lookups), and gives best practices (prefer targeted calls over 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?
No annotations provided, but the description sufficiently discloses the tool's scope (orienting, non-search, category listing). Minor gap: no mention of output structure or side effects, but for a read-only listing it is adequate.
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 compact and front-loaded with essential information, but could slightly benefit from bullet points for readability. No redundant sentences.
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, the description hints at return structure ('list available...') and enumerates categories, which is sufficient for a simple listing tool. Slightly lacking in detail about what the response looks like.
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 0% schema description coverage, the description adds rich meaning to the single optional enum parameter by listing categories and providing examples of sub-namespaces, fully compensating for the schema gap.
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 specific verbs ('list') and resources ('doc categories and their namespaces'), explicitly states it is NOT a content search, and implicitly distinguishes it from sibling tools like browse and semantic_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 says 'Use once at session start (or when unsure) before applying a category=/namespace= filter to browse / semantic_search', providing clear context and excluding search use.
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 are provided, so the description fully bears the burden. It discloses O(1) exact lookup, substring fallback, return fields (name, hash, namespace, params, etc.), the findings array with id linking to get_document, and refDocs behavior (inline content vs fetchable tables with preview).
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 longer than ideal but well-organized: purpose first, then usage scenarios, then detailed response structure. Every sentence adds value, though some could be tightened. Front-loaded with main action.
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, the description comprehensively explains the return value structure (name, hash, namespace, return type, params, description, full content, findings, refDocs) and how to use each part, including edge cases like large refDocs requiring a fetch call.
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 75% (3 of 4 params described), but the description adds critical nuance: hash accepts optional '0x' prefix, name uses exact match with ILIKE substring fallback, namespace only works with name, and limit is documented with default/max/min. Examples are provided.
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 RedM/RDR3 SCRIPT natives by hash or name, with specific use cases (Citizen.InvokeNative, GetHashKey, SCREAMING_SNAKE_CASE names). It distinguishes from sibling tools like grep_docs and get_document, making the tool's 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?
Explicit guidance on when to use this tool ('Use whenever you see Citizen.InvokeNative...') and when not to use it ('NOT for game-data hashes — use grep_docs'). It also explains parameter usage (hash or name, case-insensitivity, namespace restriction) and how to interpret results (findings, refDocs).
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, so description carries burden. Discloses 1-based inclusive indexing, 50-line default window, 400-line cap, and that the tool is the only way to access large data tables due to index limitations. Could mention error handling or permissions, but already strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and main use, but includes many conditions and examples. Every sentence earns its place, though somewhat verbose. 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 no output schema and moderate complexity, the description covers purpose, use cases, limitations, alternatives, and parameter behavior comprehensively. Leaves little ambiguity.
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% (baseline 3). Description adds meaning: start/end from grep_docs hits, omission of end yields 50 lines, path format described. Provides context beyond 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?
Clearly states 'Read an exact line range from a raw doc file by absolute line number' and positions itself as the companion to grep_docs. Differentiates from siblings like get_document, semantic_search, and lookup_native by specifying its niche.
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 (after grep_docs hit) and when not to use (prose .md → get_document, value search → grep_docs, native lookup → lookup_native). Provides clear alternatives.
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?
No annotations provided, so description carries full burden. It describes hybrid mode (RRF over vector+BM25), pure semantic/lexical modes, default community findings merge, retry behavior, and output structure (ranked snippets with path, breadcrumb, heading, snippet, score). Adequately explains behavior beyond schema.
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 a single paragraph but well-structured: starts with purpose, then usage guidance, then mode explanations, then filtering options, then retry guidance. Every sentence adds value. Could be slightly shorter or broken into subsections, but still clear and front-loaded.
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, description explains output (ranked snippets with fields) and mentions get_document follow-up. Covers all 7 parameters, 3 enums, nested object, and retry logic. Thorough for a search 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?
Schema coverage is 100% (baseline 3), but description adds significant value: explains default limit reasoning (Anthropic research), category options and community findings merge, namespace as native namespace, prior_attempt usage, and responseFormat options with use cases ('use when you need an answer in one round-trip'). Rich context.
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 differentiates itself from siblings like lookup_native (for specific hash/name) and grep_docs (for known asset names in large tables). The verb 'search' and resource 'RedM docs' are specific.
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 guidelines: '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).' 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!