What we collect

This page lists product telemetry fields, public agent feedback, retention, and opt-out controls.

Telemetry is on by default. A random installation identifier measures installations, not people. Source code, prompts, and project paths are excluded.

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.
• For scout only: what a completed semantic index build embedded. It sends a duration bucket, order-of-magnitude buckets for the files and chunks embedded, whether the build was cold, and the configured worker allowance. It also sends a coarse cache-hit rate: a 0–10 decile of how much of the build came from the local embedding cache instead of re-embedding. No file names, paths, or content.
• 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. JGlider will retain its own class and method frames under jglider.. Other frames become <external>. 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. JGlider will report the build tool, module and file count buckets, target Java level, and load duration bucket. Java facts will describe recognized Lombok JAR entries in exported classpaths and entries on exported processor paths. Facts use present, absent, or unknown when the model lacks evidence. These facts do not detect implicit processor discovery or execution.
• 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.
• In Glider, GliderTrace, TGlider, and Scout, send_feedback also sends the id of that report — a random GUID we show you and publish on the public issue. Telemetry links this id to your session, so we can trace a report’s usage. The report’s text never travels here. The feedback database below also keeps this id; on this channel it follows the telemetry retention. JGlider will use the same report-id link when its feedback channel becomes available.
• 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 projected Grafana event contains no IP address. Cloudflare processes request metadata separately.

What product telemetry never collects

• 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.

Local error history

Glider 12.3.0 and GliderTrace 1.3.0 keep unexpected product failures under ~/.glidermcp/diagnostics/. Local recording is on by default, including with --no-telemetry or DO_NOT_TRACK=1. The records stay on your device and never enter a later upload queue.

TGlider development builds add the same local history and its status. This feature is unreleased and absent from TGlider 2.0.1. Local records remain separate from telemetry and feedback.

Each JSON line holds the product and version, UTC time, local process and error ids, a fixed failure boundary and reason, a recognized tool name when available, a safe exception type, projected frames, and a grouping hash. Records omit source, paths, tool arguments, commands, tokens, and arbitrary exception data. Treat them as potentially sensitive even after projection.

While a server runs, it checks for expired inactive files at startup and hourly. It keeps at most 20 MiB per product, with 5 MiB per file and 16 KiB per record. A record can remain beyond 14 days while no server runs or while its file is active. Storage failure or a full journal can cause a record to be dropped.

Set GLIDER_LOCAL_ERROR_LOG=0 where you launch a server, then restart it, to disable new local error records. false, no, and off also work. This setting does not change telemetry or feedback. Older records can remain.

Glider 12.3.0 and GliderTrace 1.3.0 do not yet expose journal status. In development builds with local journal status, ask your agent to check server_status or trace_status when you want help with a product failure. The localErrorJournal status shows the directory, file pattern, schema version, retention limits, and cached write state. It returns no records and performs no filesystem checks.

The directory and product file pattern also identify files from earlier processes. In TGlider development builds, availability remains unknown until this process observes a successful write or storage failure. The status reports opted_out when local records are disabled.

If you authorize a host file tool, the agent can read the smallest relevant time range and prepare a redacted excerpt. Otherwise, use the path to provide an excerpt yourself. An excerpt read into a remote model can reach its provider. Local persistence does not authorize a report or attachment.

send_feedback accepts an abstract report. Its public workflow rejects paths, code, and stack traces. Use a reviewed excerpt only for local diagnosis or an authorized private channel. The journal is never attached or uploaded automatically. Do not enable telemetry to submit feedback. If submission is unavailable, prepare a draft for an authorized channel.

Feedback your agent sends

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, and GliderTrace, TGlider, and Scout ship it too. JGlider support is planned; its default development builds send no reports. Feedback is separate from automatic telemetry and can carry text that you or your agent wrote.

Glider development builds can include an invented, small code example in feedback. The agent can preview the public issue and duplicate comment locally. It must show you the complete preview, obtain your explicit approval, and then send the same content. The server does not store the preview or verify approval. Your MCP client controls whether tool calls require approval.

• What the agent writes: a category, a message of at most 500 Unicode scalar values, 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. Glider development builds can add optional reproduction status, workspace-match status, and abstract steps, expected result, actual result, and context, each limited to 500 Unicode scalar values.
• What an approved synthetic report adds in Glider development builds: run instructions and one to six invented files with relative names ending in .cs, .csproj, or .md. Files hold at most 8 KiB each and 16 KiB together. The agent supplies the content; the server does not read your project files or run the example. The reproduction status states what the agent reports it tested. The server cannot prove the test ran.
• 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 or duplicate comment in our support repository on GitHub, and the tool gives you the link. An approved synthetic example, its instructions, and the abstract evidence appear there too. The issue carries the report id, but never your install id or session id. We can link the report id to your session through telemetry; the public record cannot.
• What we keep: the message, optional evidence and approved synthetic example, product facts, and identifiers are stored in our database. Scheduled cleanup deletes filed, duplicate, and failed records once their last status update is more than 30 days old.
• We keep reports available if they require publication or a retry. Provider backups follow separate retention. The public issue can remain after closure or archival.
• Cloudflare uses the request IP address for a short edge rate limit. Our daily counter stores only a salted hash, which expires after 24 hours.
• What it refuses: ordinary feedback text and evidence that read like code, a path, a secret, or a stack trace are rejected. The separate synthetic filter permits invented code and relative fixture names, but rejects detected secrets, stack traces, and machine paths. Both checks are filters, not proof that content is safe. Review the full preview before approving publication.
• Ordinary feedback returns what was published, plus the link. A synthetic report first returns the complete prospective issue and duplicate comment for review; publication returns its status and issue link. Neither result includes the install id or 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 telemetry.glidermcp.com. Cloudflare processes request metadata at the network edge. The service derives your country and forwards filtered event fields to Grafana Cloud. It does not forward your IP address in the event record. 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 telemetry events are stored locally in a small capped file under ~/.glidermcp/, separate for each product, and sent the next time the server runs. JGlider will use spool-jglider.jsonl. CI runs are tagged so they can be told apart from interactive use.

We keep telemetry while needed to compare product versions, investigate reliability, and measure feature use. The active Grafana Cloud policy retains product logs for 14 days. Cloudflare request logs are separate and follow provider-controlled retention. We have not verified their retention period; the Grafana period does not apply to them.

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.
• jglider (Java): telemetry and feedback are planned. Default development builds send neither. These disclosures apply before the first enabled release.
• glider-trace (.NET runtime evidence): telemetry enabled (same telemetry 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 telemetry 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 telemetry 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.