Question

[mikahoy045]

I just confuse with how it work to pair with codex. I did make and run the docker, use existing .env that come with this repository. config the mcp url with codex config.toml (did some couple debug to check why it doesnt work), now it's working. but there's a several question I want to ask.

I mean, is there any specific prompt codex to use this mcp (index and search) that can be registered in global rules since if i did not do this in prompt, it doesn't want to call the tool - if i did ask to use the tool then it will do this. or there's something wrong in my setting?

do multi repository use also should be specifically explained in the global rules also? since it has var REPO_NAME that probably different for each repo.

[voarsh2]

I was thinking it would be good if there are agentic guideline examples from maintainer - that they use to get consistent use with the stack.... ?
There are some tidbits in the readme, but not exactly Claude.MD/AGENTS.md worthy)
Might be helpful to share

@m1rl0k

[m1rl0k]

yes, I need to refine this a bit because there are many knobs and things to adjust. Currently for my consistent use, I am keeping my local env committed outside the example;

However; what I should do is break the readme up, and start a /docs/ section where we can make it much more organized and documented. @voarsh2

So latest commits, I have everything in a single “codebase” collection, you should be able to ask for reponame, however multi repo is still being tested. so any usage notes please let me know..

As for codex using to tool, right now we are having to specify its use alot, Usually I start with…

“Use my context engine(whatever you call it in your mcp file as a name) to index my repo.”

or “Excercise all the tools in my context engine toolset over mcp as a test run”

Ideally these wouldnt need to be called, and due to changes in the mcp prompt routers, they may be called differently now, am trying to figure a path forward so it can call on its own, however in the wild after first index I have seen it being used in the background..

Another problem is the agents think they dont need it until they use it, so im still thinking its the descriptions, or as you mentioned adding in a .rules that says always use context engine for context against codebase.

[voarsh2]

Quick comment - will update/comment again later

Another problem is the agents think they dont need it until they use it, so im still thinking its the descriptions, or as you mentioned adding in a .rules that says always use context engine for context against codebase.

Yeah - Claude Code, other cli's (Augment Code included, to use context engine) got some system prompt - even training, to prefer grep, etc.
Clear guidelies on "eploration, fundamentals, relationship" searching, etc, use this mcp tool. Making it real clear when to use a tool (over grep/file reads).

E.G:

Agentic AI Project Rules: When to Use MCP Qdrant-Indexer vs Grep

  Core Decision Framework

  🎯 Use MCP Qdrant-Indexer When:

  Exploration & Discovery Phase
  - "I don't know the exact file/symbol names"
  - "What handles X functionality?"
  - "Find all authentication-related code"
  - "Where is user validation implemented?"
  - "Search for caching mechanisms"
  - "Look for error handling patterns"

  Semantic & Conceptual Queries
  - Concept-based searches (not exact strings)
  - Finding related functionality across multiple files
  - Discovering dependencies and relationships
  - Cross-file pattern recognition
  - Finding implementation alternatives

  When Code Structure is Unknown
  - New codebase exploration
  - Large-scale refactoring planning
  - Understanding architectural patterns
  - Finding all instances of a concept (not just literal matches)

  ⚡ Use Grep When:

  Exact Match Scenarios
  - You know the precise string: "grep -r 'user_id.validate'"
  - Specific function name: "grep -rn 'def validate_token'"
  - Known variable: "grep -rn 'REDIS_CONNECTION'"
  - Error message hunt: "grep -rn 'Connection refused'"

  Performance Critical Searches
  - Immediate results needed
  - Simple literal string matching
  - Known file locations
  - Regex patterns for structured data

  Resource-Constrained Operations
  - Limited token budget
  - Quick verification tasks
  - Simple existence checks
  - Local development debugging

  Decision Heuristics

  🧠 Ask These Questions First:

  1. Do I know the exact string?
    - Yes → Consider grep first
    - No/Unsure → Use MCP tools
  2. Am I exploring vs verifying?
    - Exploring → MCP tools
    - Verifying → grep
  3. Is this semantic or literal?
    - Semantic/Conceptual → MCP tools
    - Literal/Exact → grep
  4. Do I need context around the match?
    - Need surrounding code → MCP tools
    - Just need location → grep

  Practical Rules

  🚫 Grep Anti-Patterns:

  # DON'T - Wasteful when semantic search needed
  grep -r "auth" .                    # → Use MCP: "authentication mechanisms"
  grep -r "cache" .                   # → Use MCP: "caching strategies"
  grep -r "error" .                   # → Use MCP: "error handling patterns"
  grep -r "database" .                # → Use MCP: "database operations"

  # DO - Efficient for exact matches
  grep -rn "UserAlreadyExists" .      # ✅ Specific error class
  grep -rn "def authenticate_user" .  # ✅ Exact function name
  grep -rn "REDIS_HOST" .            # ✅ Exact environment variable

  ✅ MCP Tool Patterns:

  # DO - Use semantic understanding
  "Find all input validation mechanisms"
  "Locate database connection handling"
  "Search for performance bottlenecks"
  "Find all places where user sessions are managed"
  "Look for logging patterns and error reporting"

  Token Optimization Strategies

  MCP Tool Configuration for Efficiency:

  # Quick discovery (low token cost)
  limit=3, per_path=1, include_snippet=false, compact=true

  # Detailed analysis (higher token cost)
  limit=8, per_path=2, include_snippet=true, context_lines=5

  # Focused investigation (balanced)
  limit=5, per_path=1, include_snippet=true, context_lines=3

  Hybrid Approach Examples

  Example 1: Debugging Unknown Error

  # 1. Start broad (MCP)
  "What handles session timeouts and cleanup?"

  # 2. Get specific files and functions
  # → Returns: session_manager.py:150-180 (cleanup_sessions)
  # → Returns: auth/middleware.py:45-60 (timeout_handler)

  # 3. Switch to grep for precise pattern matching
  grep -rn "cleanup_sessions" session_manager.py
  grep -rn "timeout_handler" auth/middleware.py

  # 4. Return to MCP for related concepts
  "Find all session invalidation patterns"

  Example 2: Feature Implementation

  # 1. Understand existing patterns (MCP)
  "How are email notifications currently implemented?"

  # 2. Identify key components and exact names
  # → Returns: notification_service.py, email_adapter.py

  # 3. Use grep for implementation details
  grep -rn "send_email" notification_service.py
  grep -rn "EmailAdapter" email_adapter.py

  # 4. Search for similar patterns (MCP)
  "Find other service adapters following the same pattern"

  Decision Tree

  Do you know the exact string/function/variable name?
    ├─ Yes → Use grep first
    │     └─ Need broader context? → Then use MCP
    │
    └─ No → Use MCP tools
          ├─ Too many results? → Add filters (language, path, limit)
          ├─ Still too broad? → Get specific, then use grep
          └─ Need related concepts? → Use context_answer or semantic search

  Token Budgeting Guidelines

  Small Operations (< 100 tokens):

  - Simple existence checks: Use grep
  - Known string locations: Use grep
  - Quick verification: Use grep

  Medium Operations (100-500 tokens):

  - Concept exploration: MCP with limits=3-5
  - Pattern discovery: MCP with compact=true
  - Cross-file relationships: MCP with per_path=1

  Large Operations (> 500 tokens):

  - Comprehensive analysis: MCP with higher limits
  - Architecture understanding: MCP with include_snippet=true
  - Deep code exploration: Progressive MCP + grep hybrid

  Memory Efficiency Rules

  Prioritize MCP Tools When:

  - Result quality matters more than speed
  - Semantic understanding is crucial
  - You need to avoid false positives
  - Token budget allows for deeper analysis

  Prioritize Grep When:

  - Speed is critical
  - You have exact match information
  - Token budget is extremely limited
  - Operating in resource-constrained environments

  Final Rule of Thumb

  "Search with MCP when discovering, grep when verifying."

  If you find yourself running the same grep multiple times with different variations, you should have used MCP tools first. If you're
  searching for a known string in known files, grep is the right choice.

  MCP Qdrant-Indexer Specific Knobs

  Essential Parameters:

  - limit: Control result count (3-8 for efficiency)
  - per_path: Limit results per file (1-2 prevents redundancy)
  - compact=true: Reduces token usage by 60-80%
  - include_snippet=false: Headers only when speed matters
  - collection: Target specific codebases for precision

  Performance Optimization:

  - Start with limit=3, compact=true for discovery
  - Increase to limit=5, include_snippet=true for details
  - Use language and under filters to narrow scope
  - Set rerank_enabled=false for faster but less accurate results

  When to Use Advanced Features:

  - rerank_enabled=true: For complex queries needing best relevance
  - context_lines=5+: When you need implementation details
  - multiple collections: Cross-repo architectural analysis
  - symbol filtering: When looking for specific function/class types

  Anti-Patterns to Avoid:

  - Don't use limit=20 with include_snippet=true (token waste)
  - Don't search without collection specification (noise)
  - Don't ignore per_path limits (duplicate results from same file)
  - Don't use context lines for pure discovery (unnecessary tokens)
  

[voarsh2]

Ideally these wouldnt need to be called, and due to changes in the mcp prompt routers, they may be called differently now, am trying to figure a path forward so it can call on its own, however in the wild after first index I have seen it being used in the background..

Not really sure what's going on with this file, nor with ctx (prompt enhance cli) - couldn't get it working out of box with http indexer mcp service.

[mikahoy045]

yes, I need to refine this a bit because there are many knobs and things to adjust. Currently for my consistent use, I am keeping my local env committed outside the example;

However; what I should do is break the readme up, and start a /docs/ section where we can make it much more organized and documented. @voarsh2

So latest commits, I have everything in a single “codebase” collection, you should be able to ask for reponame, however multi repo is still being tested. so any usage notes please let me know..

As for codex using to tool, right now we are having to specify its use alot, Usually I start with…

“Use my context engine(whatever you call it in your mcp file as a name) to index my repo.”

or “Excercise all the tools in my context engine toolset over mcp as a test run”

Ideally these wouldnt need to be called, and due to changes in the mcp prompt routers, they may be called differently now, am trying to figure a path forward so it can call on its own, however in the wild after first index I have seen it being used in the background..

Another problem is the agents think they dont need it until they use it, so im still thinking its the descriptions, or as you mentioned adding in a .rules that says always use context engine for context against codebase.

I made to make it work, there's a couple of things need to modified as if we want to make it work in codex and multi repo (where the filter wouldn't work), I've made and adjustment for this but since someone already start the multirepo and remote deployment I think that should be fix when it done. I've set the prompt in global rule so it can always call the repo:

### Context-first retrieval (blended)
IMPORTANT!!!: 
Always replace <CURRENT_REPO_NAME> with the repo you’re working on (use the repo folder name or the watcher’s REPO_NAME value) so every context_search call includes "repo": "<CURRENT_REPO_NAME>" and stays scoped to that repository.

Before solving:
- Call context_engine_indexer.context_search with:
  {
    "query": "<your question>",
    "limit": 5,
    "include_memories": true,
    "include_snippet": true,
    "context_lines": 2,
    "repo": "<CURRENT_REPO_NAME>"
  }
- If empty, retry with 1–2 alternate phrasings.
- Optional per-source bias:
  {"query":"<your question>","include_memories":true,"per_source_limits":{"code":5,"memory":3},"repo":"<CURRENT_REPO_NAME>"}

Note that in the current repository the "repo" key would be ignored by indexed search and will still retrieve mixed results, until I registered it in the context_search (and some other part also)

Codex would not allow the mcp run from localhost also, I use cloudflare to tunnel my codex connection to mcp

after all this, it work like a charm:

[mikahoy045]

Quick comment - will update/comment again later

Another problem is the agents think they dont need it until they use it, so im still thinking its the descriptions, or as you mentioned adding in a .rules that says always use context engine for context against codebase.

Yeah - Claude Code, other cli's (Augment Code included, to use context engine) got some system prompt - even training, to prefer grep, etc. Clear guidelies on "eploration, fundamentals, relationship" searching, etc, use this mcp tool. Making it real clear when to use a tool (over grep/file reads).

E.G:

Agentic AI Project Rules: When to Use MCP Qdrant-Indexer vs Grep

  Core Decision Framework

  🎯 Use MCP Qdrant-Indexer When:

  Exploration & Discovery Phase
  - "I don't know the exact file/symbol names"
  - "What handles X functionality?"
  - "Find all authentication-related code"
  - "Where is user validation implemented?"
  - "Search for caching mechanisms"
  - "Look for error handling patterns"

  Semantic & Conceptual Queries
  - Concept-based searches (not exact strings)
  - Finding related functionality across multiple files
  - Discovering dependencies and relationships
  - Cross-file pattern recognition
  - Finding implementation alternatives

  When Code Structure is Unknown
  - New codebase exploration
  - Large-scale refactoring planning
  - Understanding architectural patterns
  - Finding all instances of a concept (not just literal matches)

  ⚡ Use Grep When:

  Exact Match Scenarios
  - You know the precise string: "grep -r 'user_id.validate'"
  - Specific function name: "grep -rn 'def validate_token'"
  - Known variable: "grep -rn 'REDIS_CONNECTION'"
  - Error message hunt: "grep -rn 'Connection refused'"

  Performance Critical Searches
  - Immediate results needed
  - Simple literal string matching
  - Known file locations
  - Regex patterns for structured data

  Resource-Constrained Operations
  - Limited token budget
  - Quick verification tasks
  - Simple existence checks
  - Local development debugging

  Decision Heuristics

  🧠 Ask These Questions First:

  1. Do I know the exact string?
    - Yes → Consider grep first
    - No/Unsure → Use MCP tools
  2. Am I exploring vs verifying?
    - Exploring → MCP tools
    - Verifying → grep
  3. Is this semantic or literal?
    - Semantic/Conceptual → MCP tools
    - Literal/Exact → grep
  4. Do I need context around the match?
    - Need surrounding code → MCP tools
    - Just need location → grep

  Practical Rules

  🚫 Grep Anti-Patterns:

  # DON'T - Wasteful when semantic search needed
  grep -r "auth" .                    # → Use MCP: "authentication mechanisms"
  grep -r "cache" .                   # → Use MCP: "caching strategies"
  grep -r "error" .                   # → Use MCP: "error handling patterns"
  grep -r "database" .                # → Use MCP: "database operations"

  # DO - Efficient for exact matches
  grep -rn "UserAlreadyExists" .      # ✅ Specific error class
  grep -rn "def authenticate_user" .  # ✅ Exact function name
  grep -rn "REDIS_HOST" .            # ✅ Exact environment variable

  ✅ MCP Tool Patterns:

  # DO - Use semantic understanding
  "Find all input validation mechanisms"
  "Locate database connection handling"
  "Search for performance bottlenecks"
  "Find all places where user sessions are managed"
  "Look for logging patterns and error reporting"

  Token Optimization Strategies

  MCP Tool Configuration for Efficiency:

  # Quick discovery (low token cost)
  limit=3, per_path=1, include_snippet=false, compact=true

  # Detailed analysis (higher token cost)
  limit=8, per_path=2, include_snippet=true, context_lines=5

  # Focused investigation (balanced)
  limit=5, per_path=1, include_snippet=true, context_lines=3

  Hybrid Approach Examples

  Example 1: Debugging Unknown Error

  # 1. Start broad (MCP)
  "What handles session timeouts and cleanup?"

  # 2. Get specific files and functions
  # → Returns: session_manager.py:150-180 (cleanup_sessions)
  # → Returns: auth/middleware.py:45-60 (timeout_handler)

  # 3. Switch to grep for precise pattern matching
  grep -rn "cleanup_sessions" session_manager.py
  grep -rn "timeout_handler" auth/middleware.py

  # 4. Return to MCP for related concepts
  "Find all session invalidation patterns"

  Example 2: Feature Implementation

  # 1. Understand existing patterns (MCP)
  "How are email notifications currently implemented?"

  # 2. Identify key components and exact names
  # → Returns: notification_service.py, email_adapter.py

  # 3. Use grep for implementation details
  grep -rn "send_email" notification_service.py
  grep -rn "EmailAdapter" email_adapter.py

  # 4. Search for similar patterns (MCP)
  "Find other service adapters following the same pattern"

  Decision Tree

  Do you know the exact string/function/variable name?
    ├─ Yes → Use grep first
    │     └─ Need broader context? → Then use MCP
    │
    └─ No → Use MCP tools
          ├─ Too many results? → Add filters (language, path, limit)
          ├─ Still too broad? → Get specific, then use grep
          └─ Need related concepts? → Use context_answer or semantic search

  Token Budgeting Guidelines

  Small Operations (< 100 tokens):

  - Simple existence checks: Use grep
  - Known string locations: Use grep
  - Quick verification: Use grep

  Medium Operations (100-500 tokens):

  - Concept exploration: MCP with limits=3-5
  - Pattern discovery: MCP with compact=true
  - Cross-file relationships: MCP with per_path=1

  Large Operations (> 500 tokens):

  - Comprehensive analysis: MCP with higher limits
  - Architecture understanding: MCP with include_snippet=true
  - Deep code exploration: Progressive MCP + grep hybrid

  Memory Efficiency Rules

  Prioritize MCP Tools When:

  - Result quality matters more than speed
  - Semantic understanding is crucial
  - You need to avoid false positives
  - Token budget allows for deeper analysis

  Prioritize Grep When:

  - Speed is critical
  - You have exact match information
  - Token budget is extremely limited
  - Operating in resource-constrained environments

  Final Rule of Thumb

  "Search with MCP when discovering, grep when verifying."

  If you find yourself running the same grep multiple times with different variations, you should have used MCP tools first. If you're
  searching for a known string in known files, grep is the right choice.

  MCP Qdrant-Indexer Specific Knobs

  Essential Parameters:

  - limit: Control result count (3-8 for efficiency)
  - per_path: Limit results per file (1-2 prevents redundancy)
  - compact=true: Reduces token usage by 60-80%
  - include_snippet=false: Headers only when speed matters
  - collection: Target specific codebases for precision

  Performance Optimization:

  - Start with limit=3, compact=true for discovery
  - Increase to limit=5, include_snippet=true for details
  - Use language and under filters to narrow scope
  - Set rerank_enabled=false for faster but less accurate results

  When to Use Advanced Features:

  - rerank_enabled=true: For complex queries needing best relevance
  - context_lines=5+: When you need implementation details
  - multiple collections: Cross-repo architectural analysis
  - symbol filtering: When looking for specific function/class types

  Anti-Patterns to Avoid:

  - Don't use limit=20 with include_snippet=true (token waste)
  - Don't search without collection specification (noise)
  - Don't ignore per_path limits (duplicate results from same file)
  - Don't use context lines for pure discovery (unnecessary tokens)
  

for using this context engine in multi repo mode, you need to show the query format, since this context engine default running in single repo.

[voarsh2]

for using this context engine in multi repo mode, you need to show the query format, since this context engine default running in single repo.

My "rules" was just a quick draft/mock.
Would need to experiment with writing project rules/guidelines that enforce/override "grep" tendencies - i.e THE right TOOL for the right job...

I made to make it work, there's a couple of things need to modified as if we want to make it work in codex and multi repo (where the filter wouldn't work), I've made and adjustment for this but since someone already start the multirepo and remote deployment I think that should be fix when it done. I've set the prompt in global rule so it can always call the repo:

The filter works (repo search) - ask agent to specify a specific collection name, to include in query.... Or ask it to set session default - then it sets the collection for the session and specifying the collection is not required for further queries
E.G:
● qdrant-indexer - repo_search (MCP)(query: "broadcast position update", limit: "5", per_path: "2",
include_snippet: "true", context_lines: "3", collection:
"pirates-online-classic-5a8770e1", compact: "false")

qdrant-indexer - set_session_defaults (MCP)(kwargs: "{"collection": "pirates-online-classic-5a8770e1"}")
⎿ {
"result": {
"ok": true,
… +7 lines (ctrl+o to expand)

[mikahoy045]

for using this context engine in multi repo mode, you need to show the query format, since this context engine default running in single repo.

My "rules" was just a quick draft/mock. Would need to experiment with writing project rules/guidelines that enforce/override "grep" tendencies - i.e THE right TOOL for the right job...

I made to make it work, there's a couple of things need to modified as if we want to make it work in codex and multi repo (where the filter wouldn't work), I've made and adjustment for this but since someone already start the multirepo and remote deployment I think that should be fix when it done. I've set the prompt in global rule so it can always call the repo:

The filter works (repo search) - ask agent to specify a specific collection name, to include in query.... Or ask it to set session default - then it sets the collection for the session and specifying the collection is not required for further queries E.G: ● qdrant-indexer - repo_search (MCP)(query: "broadcast position update", limit: "5", per_path: "2", include_snippet: "true", context_lines: "3", collection: "pirates-online-classic-5a8770e1", compact: "false")

qdrant-indexer - set_session_defaults (MCP)(kwargs: "{"collection": "pirates-online-classic-5a8770e1"}") ⎿ { "result": { "ok": true, … +7 lines (ctrl+o to expand)

I use the previous repository before it PR with yours, the filter is not working there so I made an adjustment there. I've clone a new one with your PR, but could you write the step by step for multi repo that work with remote deploy? I found that there's no update documentation about that

[voarsh2]

TL;DR

• “Filter” is not a field. Multi‑repo is via the collection parameter. Pre‑PR forks don’t forward collection; update to upstream main: Add multi-collection support and remote delta upload tooling #20
• Local stack: watcher + indexer container auto‑ingest from /work. No remote upload client needed.
• Remote stack: run upload_service and use the standalone remote upload client to push deltas. Point MCP config at the remote LAN IP.
• Internet exposure is out of scope for this issue:
  • Cloudflare only proxies 80/443. If you need public access, set up your own reverse proxy (e.g., subdomains mapping 80/443 → internal 8000/8001) and handle TLS/headers/SSE yourself.

---

Choose your mode

Local (non‑remote)

• Use docker-compose.yml.
• Place repo(s) under the host path mounted to /work (HOST_INDEX_PATH). The watcher + indexer will auto‑ingest.
• .env:
  • MULTI_REPO_MODE=0 → single COLLECTION_NAME (e.g., codebase)
  • MULTI_REPO_MODE=1 → per‑repo collections; pass collection on queries or set a session default
• MCP config points to localhost.

Remote

• Run the stack on another machine (docker-compose.dev-remote.yml).
• Use the standalone remote upload client to send deltas.
• Update MCP config to <lan-ip>:port.

---

MCP config

Local

```json
{
  "mcpServers": {
    "qdrant-indexer": {
      "command": "npx",
      "args": ["mcp-remote", "http://localhost:8001/sse", "--transport", "sse-only"],
      "env": {}
    },
    "memory": {
      "command": "npx",
      "args": ["mcp-remote", "http://localhost:8000/sse", "--transport", "sse-only"],
      "env": {}
    }
  }
}

Remote (replace with LAN IP)

{
  "mcpServers": {
    "qdrant-indexer": {
      "command": "npx",
      "args": ["mcp-remote", "http://<lan-ip>:8001/sse", "--transport", "sse-only"],
      "env": {}
    },
    "memory": {
      "command": "npx",
      "args": ["mcp-remote", "http://<lan-ip>:8000/sse", "--transport", "sse-only"],
      "env": {}
    }
  }
}

Remote stack bring‑up
docker compose -f docker-compose.dev-remote.yml up -d

upload_service: container :8002, exposed on host :8004

Standalone remote upload client (only for remote mode)
Optional path mapping if your host workspace differs:
export HOST_ROOT=/absolute/host/path/to/dev-workspace
export CONTAINER_ROOT=/work

Initial ingest:

python remote_upload_client.py \
  --path /absolute/host/path/to/repo \
  --endpoint http://<lan-ip>:8004 \
  --force

Continuous watch:

python remote_upload_client.py \
  --path /absolute/host/path/to/repo \
  --endpoint http://<lan-ip>:8004 \
  --watch --interval 5

Show mapping:

python remote_upload_client.py \
  --path /absolute/host/path/to/repo \
  --endpoint http://<lan-ip>:8004 \
  --show-mapping

Query format (multi‑repo)
Per‑repo query (pass collection):
qdrant-indexer - repo_search (MCP)(
query: "broadcast position update",
limit: "5",
per_path: "2",
include_snippet: "true",
context_lines: "3",
collection: "pirates-online-classic-5a8770e1",
compact: "false"
)

Set session default collection (then omit collection in subsequent calls):
qdrant-indexer - set_session_defaults (MCP)(
kwargs: "{"collection": "pirates-online-classic-5a8770e1"}"
)

Notes

Use collection to scope per repo. Older forks won’t work.
Local stack already watches/ingests; remote requires upload_service + remote client.
Cross‑repo: call repo_search per collection
If errors occur on upstream main, attach logs. Non‑updated forks won’t be troubleshot.

[mikahoy045]

Fresh Deployed on VPS Ubuntu 22.04 (Remote), I did setup my own reverse proxy, etc.

Have some issue, but I made to handle it:

• set .env MULTI_REPO_MODE=1
• create a .codebase folder:

# just change `dev-workspace` with same one in .env
mkdir -p ~/Context-Engine/dev-workspace
mkdir -p ~/Context-Engine/.codebase
sudo chown -R 1000:1000 ~/Context-Engine/dev-workspace
sudo chown -R 1000:1000 ~/Context-Engine/.codebase

• modify the LLAMA_ARG_CTX_SIZE inside docker-compose.dev-remote.yml

# this should be less than the server RAM size
LLAMA_ARG_CTX_SIZE=4096

• download llamacp model (it wont download automatically)

cd ~/Context-Engine/models
curl -L -o model.gguf https://huggingface.co/TheBloke/Llama-2-7B-GGUF/resolve/main/llama-2-7b.Q4_K_M.gguf
chmod 644 model.gguf

• at some point my docker logs init-paylload-dev-remote shown some error, I need to patch it like this, till I got ok for all health check

curl -X PATCH http://localhost:6333/collections/codebase \
  -H "Content-Type: application/json" \
  -d '{
        "hnsw_config": {
          "m": 16,
          "ef_construct": 256
        }
      }'

• at somepoint it failed to detect the codebase, I just reset the network if there's any multiple network

docker compose -p context-engine down

some helpfull command to do the debug I used :

curl -s http://localhost:6333/collections | jq

Global prompt same with the one that you previously said, but I add (CMIIW):

## Query RULES!!
- example the folder path is "pirates-online-classic"
- You must use the mcp to check which collection available, and match it based on folder path, you can use `qdrant-list` tool from qdrant-indexer mcp
- collection name format will be : <folderpath>-uniqueid
- example collection name is : pirates-online-classic-5a8770e1
- when you query, you must include collection name where the format is : <folderpath>-uid

## Example Query
(
query: "broadcast position update",
limit: "5",
per_path: "2",
include_snippet: "true",
context_lines: "3",
collection: "pirates-online-classic-5a8770e1",
compact: "false"
)

as you see, we put the collection name there.

voila:

I'm making the remote upload VSC extension (I can send pr for this)

i hope that all this information can help. Big Thanks to both of you

[John-Donalson]

awesome work!

[m1rl0k]

The context engi

Fresh Deployed on VPS Ubuntu 22.04 (Remote), I did setup my own reverse proxy, etc.

Have some issue, but I made to handle it:

• set .env MULTI_REPO_MODE=1
• create a .codebase folder:

# just change `dev-workspace` with same one in .env
mkdir -p ~/Context-Engine/dev-workspace
mkdir -p ~/Context-Engine/.codebase
sudo chown -R 1000:1000 ~/Context-Engine/dev-workspace
sudo chown -R 1000:1000 ~/Context-Engine/.codebase

• modify the LLAMA_ARG_CTX_SIZE inside docker-compose.dev-remote.yml

# this should be less than the server RAM size
LLAMA_ARG_CTX_SIZE=4096

• download llamacp model (it wont download automatically)

cd ~/Context-Engine/models
curl -L -o model.gguf https://huggingface.co/TheBloke/Llama-2-7B-GGUF/resolve/main/llama-2-7b.Q4_K_M.gguf
chmod 644 model.gguf

• at some point my docker logs init-paylload-dev-remote shown some error, I need to patch it like this, till I got ok for all health check

curl -X PATCH http://localhost:6333/collections/codebase \
  -H "Content-Type: application/json" \
  -d '{
        "hnsw_config": {
          "m": 16,
          "ef_construct": 256
        }
      }'

• at somepoint it failed to detect the codebase, I just reset the network if there's any multiple network

docker compose -p context-engine down

some helpfull command to do the debug I used :

curl -s http://localhost:6333/collections | jq

Global prompt same with the one that you previously said, but I add (CMIIW):

## Query RULES!!
- example the folder path is "pirates-online-classic"
- You must use the mcp to check which collection available, and match it based on folder path, you can use `qdrant-list` tool from qdrant-indexer mcp
- collection name format will be : <folderpath>-uniqueid
- example collection name is : pirates-online-classic-5a8770e1
- when you query, you must include collection name where the format is : <folderpath>-uid

## Example Query
(
query: "broadcast position update",
limit: "5",
per_path: "2",
include_snippet: "true",
context_lines: "3",
collection: "pirates-online-classic-5a8770e1",
compact: "false"
)

as you see, we put the collection name there.

voila:

I'm making the remote upload VSC extension (I can send pr for this) i hope that all this information can help. Big Thanks to both of you

this is awesome, ive published to marketplace, minor change as Context-Engine... please feel free to discord me .mirlok and I can provide the PAT to update as you like or invite you to the project

[voarsh2]

this is awesome, ive published to marketplace, minor change as Context-Engine... please feel free to discord me .mirlok and I can provide the PAT to update as you like or invite you to the project

I'll also be taking a stab at making the extension code a bit cleaner/maintainable.... as per: #22 (comment)

I've also added you on Discord (Armageddon131)

[mikahoy045]

Thanks @m1rl0k , I drop you both friend request on discord. I drop some comments on #22 probably we can discuss about it.