Skip to main content
Glama

Hybrid search RedM docs (semantic + lexical)

semantic_search
Read-only

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoRetrieval mode. Default hybrid (recommended).
limitNoHow many ranked snippets to return. Default 20 (Anthropic contextual-retrieval research: top-20 outperforms top-5/10 before reranking).
queryYesNatural language or token query
categoryNoLimit to one doc category
namespaceNoLimit to a native namespace, e.g. PLAYER, ENTITY
prior_attemptNoPopulate ONLY when retrying after a previous semantic_search call returned no useful results. Skip on first attempts.
responseFormatNo`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

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are minimal (readOnlyHint=true, openWorldHint=false). The description goes far beyond them by disclosing hybrid mode mechanics (RRF over vector + BM25), the exact result format (path, breadcrumb, heading, snippet, score), default merging of community findings, mode-specific behavior (semantic vs lexical), and the special `prior_attempt` server behavior for retries. No annotation contradiction; this is fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but every sentence carries critical information: purpose, alternatives, mode semantics, output format, follow-up action, filters, and retry behavior. It is front-loaded with the purpose statement and structured with clear operational details. Given the tool's complexity (7 parameters, multiple modes, nested objects), the length is appropriate and not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a read-only search tool with no output schema, so the description must carry the full burden of explaining return values and behavior. It states exactly what is returned (ranked snippets with path, breadcrumb, heading, snippet, score), how to retrieve full content, how modes differ, how filters work, and the `prior_attempt` improvement mechanism. It is fully 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds meaningful semantic context beyond the schema: it explains what 'hybrid' means with concrete examples, clarifies the effect of `category=learnings`, and defines when to use `prior_attempt`. It does not explicitly discuss `limit`, `namespace`, or `responseFormat`, but these are already well-documented in the schema. Thus it adds genuine value above the structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource+scope: 'Search RedM/RDR3 docs by behavior, concept, OR exact token.' It also distinguishes itself from siblings by explicitly naming when to use `lookup_native` (specific native hash/name) and `grep_docs` (known asset names in large data tables). This is a model of purpose clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use instructions: '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 tells the agent to call `get_document` for full content and explains when to populate `prior_attempt` (after a failed search). This fully covers usage context and exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: asset_lookup handles game-asset hashes/names, lookup_native handles script natives, grep_docs does exact token search, semantic_search handles concept/behavior queries, browse/list_namespaces orient, get_document/read_lines retrieve content, get_invoke_guide is a specialized reference, and share_finding contributes. The descriptions explicitly cross-reference when NOT to use each tool, eliminating ambiguity.

Naming Consistency4/5

Most tools follow verb_noun pattern (get_document, grep_docs, list_namespaces, lookup_native, read_lines, share_finding), but asset_lookup uses noun_verb order, and browse is a bare verb. The deviation is minor and the pattern remains predictable.

Tool Count5/5

10 tools is well within the ideal 3-15 range. Each tool earns its place: search, retrieval, discovery, lookup, and contribution are all covered without bloat. The count matches the server's purpose as a comprehensive documentation interface.

Completeness5/5

The domain is RedM/RDR3 documentation access, and the set covers the full lifecycle: orientation (list_namespaces, browse), search (semantic_search, grep_docs, lookup_native, asset_lookup), retrieval (get_document, read_lines, get_invoke_guide), and contribution (share_finding). There are no obvious dead ends or missing operations for the stated purpose.

Resources