Skip to content

fix(mcp): don't auto-scope to a microservice absent from the index#331

Merged
HumanBean17 merged 1 commit into
masterfrom
fix/mcp-autoscope-context-dir
Jun 15, 2026
Merged

fix(mcp): don't auto-scope to a microservice absent from the index#331
HumanBean17 merged 1 commit into
masterfrom
fix/mcp-autoscope-context-dir

Conversation

@HumanBean17

Copy link
Copy Markdown
Owner

Problem

Launching the MCP server from the config/context directory (a top-level child of source_root with no build marker and no source) made every tool return empty results — even though init built the index correctly and path resolution was right.

Reproduced with the bank-chat fixture: search returned results: [] from bank-chat-context/, but real hits from the parent tests/bank-chat-system/ (where .mcp.json + the index live). Same index, same resolution — the only difference was the bogus auto-scope.

Root cause

detect_microservice_from_path mislabels any codeless top-level child of source_root as a microservice via its "first path segment under root" fallback. ScopeManager then set default_scope = 'bank-chat-context' and auto-scoped every query to a microservice with zero indexed rows → empty from all tools. The index's real microservice values are chat-core / chat-assign, so bank-chat-context matched nothing.

Fix

ScopeManager._detect_scope now validates the detected candidate against the indexed microservice set (_indexed_microservices → graph microservice_counts()). A candidate with no indexed code → None (system scope). A real microservice the operator is working in is, by definition, in the index, so this cannot suppress a legitimate scope (preserves the auto-scope feature). Empty/unreadable index keeps detection (no silent disabling).

Query-time only — no reindex required; restart the MCP server and tools return data.

User-visible behaviour change

  • MCP launched from a non-microservice dir (e.g. the config/context dir) no longer self-empties; tools return system-wide results.
  • MCP launched from inside a real, indexed microservice still auto-scopes exactly as before.

No schema, ontology, embedding, or env-var change.

Manual evidence

Drove the real stdio server from tests/bank-chat-system/bank-chat-context/:

  • Before: [scope] Detected microservice: bank-chat-contextsearch results: []
  • After: [scope] No microservice detectedsearch returns 5 (top: com.bank.chat.engine.kafka.ChatKafkaConfiguration)

Tests

tests/test_microservice_scope.py::TestScopeManagerAutoScopeValidation (4): the regression (codeless context dir → no scope), a non-regression guard (real indexed microservice dir → still scopes), the empty-index fallback, and _indexed_microservices extraction. Full non-heavy suite: 835 passed, 13 skipped.

🤖 Generated with Claude Code

Launching the MCP server from the config/context directory — a top-level
child of source_root with no build marker and no source — made
detect_microservice_from_path return that dir name via its "first path
segment under root" fallback. ScopeManager then auto-scoped every query
to a microservice with zero indexed rows, so all tools returned empty
results, even though the index was intact and path resolution was correct
(reproduced with the bank-chat fixture: search returned [] from
bank-chat-context/ but real hits from the parent).

Validate the detected scope against the indexed microservice set
(ScopeManager._indexed_microservices -> graph microservice_counts); a
candidate with no indexed code is suppressed to None (system scope). A
real microservice the operator is working in is, by definition, present
in the index, so this cannot suppress a legitimate scope. An empty or
unreadable index keeps the detected candidate (never silently disables
auto-scope).

Query-time only: no schema, ontology, embedding, or env-var change; no
reindex required.

Co-Authored-By: Claude <[email protected]>
@HumanBean17 HumanBean17 force-pushed the fix/mcp-autoscope-context-dir branch from 7ed77f3 to 49a7ada Compare June 15, 2026 12:04
@HumanBean17 HumanBean17 merged commit 8512eb4 into master Jun 15, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant