# Fix MCP tools in PostHog Desktop - Docs

**Open beta**

PostHog Desktop is in beta.

[PostHog Desktop](/docs/posthog-desktop.md) is where you act on the [Self-driving](/docs/self-driving.md) reports MCP Analytics generates. A scout reads your tool call telemetry, finds tools that need fixing, and files a report. Whether that report arrives with a pull request attached depends on who owns the server it's about.

## Whether you get a pull request depends on who owns the server

The scout can only propose a code fix for code you control, so the same finding takes one of two paths:

-   **You own the server.** Your own MCP server, instrumented with the [`@posthog/mcp` SDK](/docs/mcp-analytics/installation.md). The report carries a **fix loop metric** – the number the fix is supposed to move – and auto-starts an implementation task. The coding agent works in a sandbox against your connected repo, pushes a branch, and opens a draft pull request.
-   **You don't own the server.** You're analyzing PostHog's hosted MCP server, which is what most projects are doing. The report is filed for human review with no repository attached, and nothing opens a pull request. Read it as an upstream bug report and decide what to do with it.

Even on a server you own, a report that bundles unrelated fixes across several tools goes to a human – there's no single pull request that would cover it. The automatic path is for a concrete, localized change: a schema or description fix, or a bug in one handler.

## What the scout watches

A scout reads `$mcp_tool_call` events for tools that need attention:

-   **High failure rates** – a tool erroring far more than the rest
-   **Retries and hammering** – agents calling the same tool over and over to get what they need
-   **Slow or bloated responses** – calls that take too long or return so much that they crowd the agent's context

It weighs each of these by volume and reach, so a tool failing for one developer in one session doesn't earn a report. What clears the bar gets grouped by the team that owns the tools and filed as a single report.

## What you can do here

-   **Read the report** – the failing tool, the pattern behind it, and the evidence from real calls.
-   **Ask questions** – start a research task against the report to dig further before acting.
-   **Watch the agent work** – when there's an implementation task, follow the live transcript and review the files it changed.
-   **Merge** – the pull request opens on GitHub, and PostHog reflects the merged state back.

Nothing ships without you. The merge happens on GitHub, so a human is always the last step.

## Start a fix yourself

You don't have to wait for the scout, and you don't need it to have taken the automatic path. The **Create fix task** button on the [tool quality view](/docs/mcp-analytics/surfaces/web-app.md#tool-quality) starts the same coding agent run from a specific tool's failures.

It needs the GitHub integration connected – the button stays disabled without it – and you pick the repository the agent works in. That's the same constraint as the automatic path, just made explicit: the agent can only fix a codebase you've pointed it at.

## Related

-   Explore tool quality in the [web app](/docs/mcp-analytics/surfaces/web-app.md).
-   Learn how the loop works in the [Self-driving docs](/docs/self-driving.md).

### Community questions

Ask a question

### Was this page useful?

HelpfulCould be better