What we collect

Glider products send a small amount of anonymous usage telemetry so we can see how the tools are really used: how many people use them, on which platforms, which tools matter, and what breaks. This page lists every field, what is never collected, and how to turn it off.

Telemetry is anonymous and on by default. It never contains your source code, prompts, or anything that identifies your project. You can disable it with a single flag.

What is collected

Each MCP server sends batches of small JSON events containing only:

• A random install id (a GUID generated once and stored locally; no machine, user, or hardware fingerprinting).
• Product and version (for example, glider 6.16.0).
• Operating system and architecture (for example, macos / arm64).
• Runtime version (for example, .NET 10).
• Per tool call: the tool name, a duration bucket (not the exact time), and the outcome (success, error, timeout, or cancelled).
• Error categories: the exception type name or a stable error code only — never the message text.
• For scout only, which search route answered a search. It sends the target and match mode you asked for, and the ones that actually answered (for example, auto resolving to content and literal). It sends which tier answered, exactly as shown: lexical, structural, treesitter, semantic, or hybrid. It also sends three state flags: degraded, exhaustive, and incomplete. It sends whether the page it returned held a match, and a duration bucket rather than the exact time. What you searched for is never sent, and neither is how many results it found.
• Error fingerprints: for a failure, a short list of method names (as Namespace.Type.Method). A frame is kept only when its namespace begins with a known framework prefix (Glider., Microsoft.CodeAnalysis., Microsoft.Build., Microsoft.Extensions., System.); any other frame is collapsed to <external>. This is decided by the namespace name, not the assembly, so code you place under one of those prefixes would also be kept — but never any file path, line number, argument, or message. A grouping hash is included so identical failures can be counted. Some failures keep no frame at all. This is common, because a failure raised inside a dependency carries none of our own frames. The list then holds one fixed marker. The marker names the part of the server that caught the failure, for example tglider.unattributed.background.warmup. It is a constant of our source code, and it lets us count these failures apart from each other.
• Coarse workspace shape as counts and buckets only: number of projects and files, SDK-style vs legacy project counts, whether Central Package Management is used, target-framework families, and how long the workspace took to load (a duration bucket, not the exact time). No names or paths.
• A recognized MCP client name (for example, claude-code or cursor), or "other" — the name your client reports is matched to a known list and never forwarded verbatim.
• Server resource health, sent only when a server’s own handle count reaches a level that indicates a leak. A healthy server uses a few hundred handles. The report carries bucketed numbers only. These are the handle count, the private memory, the time the server had been running, and the thread count. It also carries how many tool calls and file-watcher events happened in the last sampling window. It says whether a workspace was loaded, roughly how many projects it held, and whether the host configuration file watcher was enabled. It is sent at most once per severity level per server run. This tells us whether a specific fix for a known leak works, which one machine cannot show.
• Country, derived at our edge from the network request. The IP address is never stored or forwarded.

What is never collected

• Source code or file contents.
• File paths, file names, symbol names, or project names.
• Search queries, and the number of results a search returned. scout’s route report says whether the page it returned held a match, never how many.
• Prompts or any LLM conversation content.
• Command arguments or environment variables.
• Raw error messages or exception text.
• Full stack traces, file paths, or line numbers — only method names whose namespace begins with a known framework prefix are kept (see the error fingerprint above); everything else is collapsed to <external>.
• Runtime evidence such as memory dumps or variable values.
• The contents of any environment variable. The resource-health report says whether one server setting was on or off; it never carries a variable’s value.

Feedback you choose to send

A send_feedback tool lets an agent report a missing capability or a poor result while you work. Glider ships it from version 10.3.0; Scout, TGlider, and GliderTrace do not have it yet, and this page will name them as they release it. It is the only channel that carries text you or your agent wrote, so it follows stricter rules than the anonymous telemetry above.

The tool description asks the agent to use it when it meets a gap and to tell you what it sent. Whether a tool can run without asking you is a setting in your MCP client. Our server cannot decide it, so the tool result repeats what was published. The switch you fully control is the last item in this list.

• What the agent writes: a category, a message of at most 500 characters, and the tool the report is about. The categories are missing capability, bad output, error, and praise. The report also names your coding agent and model. It names other MCP servers in the session only when they matter to the report.
• What the product adds: a report id generated for that report, and the product, version, operating system, architecture, and runtime facts listed above. It also adds your install id and your session id.
• Where it goes: the report becomes a public issue in our support repository on GitHub, and the tool gives you the link. The issue carries only the report id. Your install id and session id are never part of it. Two public reports therefore cannot be traced back to one machine.
• What we keep: the message, the product facts, and the two identifiers are stored in our database. The row lets us file the report and merge repeat reports. We delete it 30 days after the issue exists. The public issue itself stays until we close and archive it.
• What it refuses: a message that reads like source code, a file path, a secret, or a stack trace is rejected, not quietly edited. The tool returns the reason. The agent can then describe the problem in general terms. The check is a filter, not a proof.
• The tool result repeats what was published, plus the link, so you can see it in your conversation. It leaves out the install id and session id.
• How to turn it off: set GLIDER_FEEDBACK=0. The --no-telemetry flag and DO_NOT_TRACK=1 also disable it.

How it travels

Events are sent to a small ingest service at telemetry.glidermcp.com. The service derives your country at the network edge, drops the IP address, validates the fields, and forwards anonymized records to Grafana Cloud. Sending is best-effort.

To keep network use minimal, events are batched and sent rarely — when a small buffer fills, every few minutes, or when the server stops. If sending fails (you are offline) or the server is interrupted, the pending anonymous events are stored locally in a small capped file at ~/.glidermcp/spool.jsonl and sent the next time the server runs. CI runs are tagged so they can be told apart from interactive use.

How to turn it off

Use either of these where you launch the MCP server, then restart it:

• --no-telemetry — pass this flag to the server (in your MCP client’s args), and it sends nothing.
• DO_NOT_TRACK=1 — the standard cross-tool opt-out environment variable, also honored.

Per-product status

• glider (C#/.NET): telemetry enabled.
• glider-trace (.NET runtime evidence): telemetry enabled (same anonymous events — tool name, duration bucket, outcome, and error fingerprint). Captured runtime evidence, traces, and dumps always stay on your machine and are never sent.
• tglider (TypeScript/JavaScript): telemetry enabled (same anonymous events — tool name, duration bucket, outcome, and error fingerprint). Stack frames are reduced to method names from tglider’s own code only, or to the fixed marker described above; your code, file paths, and arguments are never sent.
• scout (universal code search): telemetry enabled (same anonymous events — tool name, duration bucket, and outcome — plus which search route answered each search). Your code, file paths, search queries, and result counts are never sent. Disable with DO_NOT_TRACK=1 or the --no-telemetry flag.