## Problem A third of `start_mcp_tool_call` events have no namespace. This blinds the flagship-account target, which depends on namespace data. The epic quotes 39.4%; a fresh 30-day measurement gives 33.3%. The exact figure moves with the window, and the numbers below are the measured ones. There are three causes. First, the current namespace lookup only checks `project_id` and `group_id` arguments. Many tools instead take a full GitLab URL, or use other argument names like `full_path` or `project_full_path`. Route-backed API tools use an `id` argument instead. For all of these, the namespace lookup finds nothing. Second, the event that starts tracking fires before the tool class is resolved. At that point, the tool's own argument shape is not known yet. Third, aggregated tools rewrite their arguments after the start event has already fired, and after the namespace lookup result has already been cached. So the rewritten arguments never reach telemetry. **Measured scope** Query window: 30 days, 2026-08-23 to 2026-09-20. Filtered to `app_id = 'gitlab'` and `event_action = 'start_mcp_tool_call'`. Missing means `dim_namespace_id IS NULL`. In this window, there were 6,853,554 calls. 2,284,272 of them had no namespace. That is 33.3%. 130 distinct tool names appeared. Grouping tools by how often they lose their namespace: | Group | Tools | Calls | Missing | Share of all missing | |---|---|---|---|---| | No container argument, so missing is expected | 10 | 74,904 | 53,121 | 2.3% | | Almost always missing (80% or more) | 50 | 1,234,163 | 1,184,725 | 51.9% | | Partly missing (20% to 80%) | 24 | 1,838,627 | 761,335 | 33.3% | | Mostly resolved (under 20%) | 46 | 3,705,860 | 285,091 | 12.5% | Only 2.3% of the missing namespaces are expected. Those are tools with no container argument at all. The other 97.7% are tools that do have a container argument, but whose argument name is not recognised. The "almost always missing" group matches tools whose container argument is not called `project_id` or `group_id`. The worst by volume: - `get_pipeline`: 252,776 calls, 98.7% missing - `get_job`: 251,031 calls, 99.1% missing - `list_pipelines`: 181,593 calls, 94.8% missing - `get_pipeline_jobs`: 159,816 calls, 97.7% missing - `get_merge_request_pipelines`: 110,090 calls, 90.7% missing - `get_issue`: 43,579 calls, 97.8% missing - `semantic_code_search`: 30,820 calls, 94.0% missing The "partly missing" group matches tools that accept either a full URL, or a project id plus an internal id. For these tools, the miss rate is roughly the share of callers who passed a URL. Examples: - `get_merge_request`: 1,116,756 calls, 41.3% missing - `get_work_item`: 167,775 calls, 51.8% missing - `save_merge_request_review`: 129,994 calls, 52.6% missing - `get_merge_request_notes`: 181,363 calls, 34.4% missing - `save_note`: 78,605 calls, 39.9% missing ## Desired outcome Every tool call should resolve a namespace, no matter which argument shape the tool uses. This includes `project_id`, `group_id`, `id`, `url`, or `full_path`-style names, and it should also work when aggregated tools rewrite their arguments. Only tools explicitly marked as "not governable" should end up with no namespace. The namespace lookup used for telemetry must never perform a permission check, since it only feeds telemetry and never the response. The start and finish events should share one lookup result, instead of each computing it separately. ## Acceptance criteria - Tools called with `url` only produce events with a namespace. - Route-backed tools called with `id` produce events with a namespace. - Aggregated tools produce events with a namespace, using the rewritten arguments. - Tools marked `ungovernable!` are the only ones left with no namespace. - A spec exists for each argument shape (project_id, group_id, id, url, full_path style names, aggregated tool rewrite). - The share of `start_mcp_tool_call` events with no namespace drops from 33.3% to under 3%, measured on the same 30-day query. - Add the resolved namespace to the `mcp.log` line so it is queryable in Kibana. - The expanded-logging consequence is stated explicitly in the change description and signed off by a reviewer, instead of shipping silently. ## Where to look - `ee/lib/ee/api/mcp/handlers/call_tool.rb:55-69` (`resolve_tracking_scope`) - `lib/api/mcp/handlers/call_tool.rb` (`invoke`, `track_start_event` runs before `fetch_tool`) - `app/services/mcp/tools/concerns/governance_namespace_resolver.rb` - `app/services/mcp/tools/base/api_tool.rb:36-42`, `:113-117` - `app/services/mcp/tools/base/aggregated_service.rb:35` - `Mcp::Tools::Concerns::UrlParser` - `prod.common_mart.mart_behavior_structured_event` in Snowflake, filtered on `app_id = 'gitlab'` and `event_action = 'start_mcp_tool_call'`. - `lib/gitlab/mcp/logger.rb` — `conditional_info`, where `fields` is always indexed and `expanded` is gated. ## Links - Epic: MCP Server instrumentation initiative — https://gitlab.com/groups/gitlab-org/-/work_items/23391 (priority 3 in the table) - Should be sequenced together with: the alias-flag issue (both need `track_start_event` moved after `fetch_tool`)