feat(mcp): instrument the remote tool-dispatch chokepoint with PostHog events

[claytonlin1110]

Summary

• Part of Spec: usage-telemetry instrumentation strategy for MCP (PostHog) #6228. handleMcpRequest (src/mcp/server.ts) is the single chokepoint every remote MCP request — including every tools/call invocation — already passes through; it already derives startedAt, usageMetadata.toolName, and success/failure to record a DB-based product-usage event. This PR reuses those exact same signals to also call the feat(mcp): add a typed PostHog wrapper module for src/mcp/server.ts (remote) #6235 PostHog wrapper's recordMcpToolCall exactly once per real tool call, tagged callerType: "remote".
• Only requests where usageMetadata.toolName is a string (i.e. an actual tools/call, not ping/tools/list/etc.) trigger recordMcpToolCall, mirroring the existing eventName: "mcp_tool_called" vs "mcp_request" guard already in this function.
• The call is wrapped in a small recordMcpToolTelemetry helper with its own try/catch, so a telemetry failure can never affect the tool response — a second, defensive layer on top of the wrapper's own no-throw guarantee from feat(mcp): add a typed PostHog wrapper module for src/mcp/server.ts (remote) #6235.
• Zero behavior change to any tool's response: the new code only reads already-computed values (c.env, usageMetadata.toolName, response.status, startedAt) and never touches the returned Response/thrown error.

Scope

• The PR title follows type(scope): short summary Conventional Commit format, for example fix(api): restore profile access checks.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves (e.g. Closes #123) — a linked open issue is required for every contributor PR.

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage locally; codecov/patch requires ≥99% coverage of the lines AND branches you changed (aim for 100% on your diff so CI variance does not fail near the threshold). Global coverage is a non-blocking trend with a loose 90% backstop, not the gate.
• npm run test:workers
• npm run build:mcp
• npm run test:mcp-pack
• npm run ui:openapi:check
• npm run ui:lint
• npm run ui:typecheck
• npm run ui:build
• npm audit --audit-level=moderate
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries

If any required check was skipped, explain why:

• This local Windows dev environment cannot run wrangler (cf-typegen:check fails with a pre-existing, change-unrelated spawnSync wrangler ENOENT), which blocks the chained npm run test:ci from reaching later steps locally. Each step was therefore run individually: git diff --check, actionlint, db:migrations:check, db:schema-drift:check, selfhost:env-reference:check, miner:env-reference:check, selfhost:validate-observability, engine build, typecheck, test:engine-parity, test:live-gate-parity, and test:driver-parity all pass clean on this branch. Coverage was verified by scoping --coverage.include to src/mcp/server.ts and running just the touched test file: every new line and both sides of both new if (typeof usageMetadata.toolName === "string") branches are fully covered. The broader test/unit/mcp-*.test.ts + test/integration/routes-errors.test.ts sweep passes cleanly aside from 3 pre-existing, change-unrelated Windows-only symlink-permission failures (EPERM: operation not permitted, symlink) in mcp-cli-lint-pr-text.test.ts/mcp-cli-slop-risk.test.ts.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests.
• API/OpenAPI/MCP behavior is updated and tested where needed.
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks.
• Visible UI changes include a UI Evidence section below — N/A, no UI change.
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs.

UI Evidence

N/A — backend-only observability change, no visible UI change.

Notes

• Closes feat(mcp): instrument the remote MCP tool-dispatch chokepoint with PostHog events #6237
• Depends on the already-merged feat(mcp): add a typed PostHog wrapper module for src/mcp/server.ts (remote) #6235 (src/mcp/telemetry.ts's recordMcpToolCall).

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-16 04:23:57 UTC}

2 files · 1 AI reviewer · no blockers · readiness 82/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR adds a defensively-wrapped call to `recordMcpToolCall` at the two existing success/failure exit points of `handleMcpRequest`, reusing already-computed `startedAt`, `usageMetadata.toolName`, and `response.status` values with zero changes to the returned response. The guard (`typeof usageMetadata.toolName === "string"`) correctly mirrors the existing `mcp_tool_called` vs `mcp_request` distinction already present in this function, and the new tests exercise both the successful-call path and the telemetry-throws path, confirming the response is unaffected either way. The change is small, well-targeted, and consistent with the described chokepoint semantics.

Nits — 4 non-blocking

• src/mcp/server.ts: the `catch {}` in `recordMcpToolTelemetry` swallows telemetry failures with no debug signal at all (not even a console.warn), which could make silent telemetry breakage hard to notice in practice.
• src/mcp/server.ts: the `typeof usageMetadata.toolName === "string"` guard is duplicated verbatim at both call sites (success and catch) — consider hoisting it into a single `const toolName = typeof usageMetadata.toolName === "string" ? usageMetadata.toolName : undefined;` computed once before the `try`, then checking `if (toolName)` at each site.
• Consider at least a `console.warn`/structured log inside the empty catch of `recordMcpToolTelemetry` so telemetry outages are observable without needing to instrument the instrumentation.
• Hoist the repeated `typeof usageMetadata.toolName === "string"` check into a single computed value shared by both call sites.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#6237
Related work	⚠️ 2 scoped overlaps	Top overlaps are listed below; lower-confidence bulk is hidden.
Change scope	❌ 8/20	High review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 382 registered-repo PR(s), 257 merged, 109 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	claytonlin1110; Gittensor profile; 382 PR(s), 109 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: minor

Linked issue satisfaction

Addressed
The PR wires recordMcpToolCall into handleMcpRequest's single chokepoint, tagging callerType 'remote' with tool name, success/failure, and duration, and wraps it in a try/catch helper so telemetry failures never affect the tool response. It includes regression tests confirming a tool call succeeds unchanged even if telemetry throws, matching the issue's requirements and deliverables.

Review context

• Author: claytonlin1110
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 382 PR(s), 109 issue(s).
• Related work: Titles/paths share 12 meaningful terms. (issue #6238, issue #6237)
• Related work: Titles/paths share 9 meaningful terms. (issue #6238, issue #6236)

Contributor next steps

• Start here: Review top overlaps.
• Then work through the remaining 2 steps in the Signals table above.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.60%. Comparing base (d6fa47a) to head (cc96f20).
⚠️ Report is 21 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6358   +/-   ##
=======================================
  Coverage   95.60%   95.60%           
=======================================
  Files         598      598           
  Lines       47202    47208    +6     
  Branches    15022    15024    +2     
=======================================
+ Hits        45128    45134    +6     
  Misses       1290     1290           
  Partials      784      784           

Flag	Coverage Δ
shard-1	43.99% <100.00%> (-0.16%)	⬇️
shard-2	36.80% <0.00%> (+0.41%)	⬆️
shard-3	32.53% <0.00%> (+<0.01%)	⬆️
shard-4	34.43% <0.00%> (-0.19%)	⬇️
shard-5	30.99% <0.00%> (-0.60%)	⬇️
shard-6	45.32% <66.66%> (+0.45%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/mcp/server.ts	96.33% <100.00%> (+0.02%)	⬆️