Repository navigation
ENH: Extend the CLI tool to incorporate indexing based on the prescribed format #2
Description
Activity
This is a valid approach, but it has significant implications for how the CodeGraphContext works, particularly
regarding shared state and background jobs:Current Architecture (
cgc start+ MCP Client):- When you run cgc start, a single MCPServer instance is launched. This server manages:
- The connection to the Neo4j database (DatabaseManager).
- All background indexing jobs (JobManager).
- The CodeWatcher for live updates.
- When an MCP client calls a tool (e.g., add_code_to_graph), it sends a request to this running server.
The server then executes the corresponding add_code_to_graph_tool method, which uses the server's shared
DatabaseManager and JobManager. This is why check_job_status and list_jobs can see all jobs created by the
server.
The Proposed CLI-Direct Approach (without a persistent server instance for each command):
If cgc add-code-to-graph directly calls a function in cli/main.py that then initializes its own DatabaseManager,
JobManager, and GraphBuilder for that single command execution:- No Shared State: Each cgc command would operate in isolation.
- If you run cgc add-code-to-graph /path/to/project, it would start an indexing job, but that job's status
would only be known to that specific command invocation. - If you then run cgc list-jobs, it would initialize a new JobManager and would not see the job created by the
previous add-code-to-graph command, nor would it see jobs created by a cgc start server.
- If you run cgc add-code-to-graph /path/to/project, it would start an indexing job, but that job's status
- No Background Processing (easily): The add_code_to_graph and add_package_to_graph tools are designed to run
indexing in the background using asyncio.run_coroutine_threadsafe(coro, self.loop). If these functions are
called directly from a synchronous CLI command that doesn't have an active asyncio event loop, the background
processing would be difficult to manage or would block the CLI until completion. - Redundant Database Connections: Every CLI command would establish and then close its own connection to Neo4j,
which is less efficient than a single persistent connection managed by a server.
Conclusion:
While simplifying the command syntax is desirable, moving the core tool logic directly into the CLI commands
(without a persistent server instance managing state) would fundamentally break the shared graph context and job
management features that CodeGraphContext provides.- When you run cgc start, a single MCPServer instance is launched. This server manages:
Index Code:
cgc tool add-code-to-graph '{"path": "/path/to/your/project"}'Also, Add other tools as well which can be used by users as a cli tool