Does linear-mcp-server send data, and where? — data-flow verdict

100/100 integrity 100% evidence coverage evidence-backed Measures evidence support, not confidence — how this is scored

Verdict (the facts)

Tool
npm/linear-mcp-server
Integrity axis
undisclosed_processing — Observed behaviour matches the tool's stated function; the egress above is the tool doing its advertised job. 'honest' is the integrity axis — it does NOT imply the data flow is irrelevant; see the data-flow axis and jurisdiction.
Data-flow axis
Sends data to api.linear.app (US, jurisdiction tier 2) as its core function. No telemetry, analytics or error-reporting side-channel was found (full source + dependency-tree review). Where your data goes is determined by the tool's stated purpose, not by a hidden observability channel.
Disclosure
functional — The only network destination is api.linear.app (Linear GraphQL API, https://api.linear.app/graphql) via @linear/sdk — exactly the API the tool exists to wrap. Zero telemetry/analytics/error-reporting: the entire published tarball (build/index.js + package.json + README) was read and grepped — no Sentry/PostHog/Segment/Amplitude/Mixpanel/Datadog/Bugsnag, no second host, no analytics strings; the only 'apiMetrics' is a LOCAL in-memory rate-limiter returned to the calling LLM, never transmitted; errors go to stderr only. Egress fires on tool-call (not launch), carrying the GraphQL operation plus LLM-supplied arguments (issue title/description, comment body, teamId, filters) and an Authorization header bearing the user's LINEAR_API_KEY.
Capture self-test
verified
Severity
low — integrity axis only (undeclared exfiltration). Functional egress and disclosed metadata are reported as neutral facts and are not graded here.
Version (pinned)
0.1.0 · commit 848423156ea3bd23e68b81e057b57ed675b07410
Content hash
sha256:a9231b985587aec1c466a683fc2cc594c7900f706d242b8613e980959c5a1cfe
Signature
ed25519:5ZiM1m3PwQMuUSDPMqczFidEr7Eu56WbsmAirk… · Ed25519 public key · sha256:49cf8457b42a7048
Scanned
2026-06-14T00:00:00Z — Pinned to linear-mcp-server@0.1.0 (git 848423156ea3bd23e68b81e057b57ed675b07410), published 2025-02-17. This verdict applies to that exact version; a newer release would require a re-scan.
Re-verified
2026-06-14 — pinned version current
Categories
project-productivity functional-egress US published
Observation history
3 scan(s); first seen 2026-06-14T00:00:00Z · latest 2026-06-14T00:00:00Z

Observed egress destinations

hostcountryjurisdictionclassdisclosurefrequencykind
api.linear.appUStier 2functionalby purposeon launch and on every tool callLinear GraphQL API — carries issue operations + LLM-supplied arguments (the tool's advertised function); the Authorization header bears the user's LINEAR_API_KEY

Each destination is classified FUNCTIONAL (the tool's advertised job requires the call — a neutral fact about where your data goes), SESSION/AUTH (handshake with the same operator), or TELEMETRY/ERROR_REPORTING (an observability side-channel not required for the function). Disclosure is judged across the tool's full public doc surface, not just its README, and any 'undisclosed telemetry' finding is adversarially refuted before it is asserted.

Jurisdiction context: Tier 2 = third country (e.g. US): transferring EU personal data to a third country requires a transfer basis under GDPR Art. 44-49 (e.g. SCCs / EU-US Data Privacy Framework) — an obligation on you, the deployer; the tool gives no control over this flow. This is the applicable framework, not a finding that the tool violates it.

Evidence — the captured request (verify, don't just trust)

Capture self-test: verified — a beacon decoy was emitted from the tool's network context; its presence in the intercept means a 'no egress' result would have been trustworthy.

Observed: POST https://api.linear.app/graphql ×5 — intercepted (the tool's HTTPS was terminated against the sandbox CA; the egress was then blocked by strict-egress, but the full request was captured)

Payload fields actually sent:

Captured payload sample (one event):

{"query":"query issues($after: String, $before: String, $filter: IssueFilter, $first: Int, $includeArchived: Boolean, $last: Int, $orderBy: PaginationOrderBy, $sort: [IssueSortInput!]) {\n  issues(\n    after: $after\n    before: $before\n    filter: $filter\n    first: $first\n    includeArchived: $includeArchived\n    last: $last\n    orderBy: $orderBy\n    sort: $sort\n  ) {\n    ...IssueConnection\n  }\n}\n\nfrag

Captured in the sandbox run. The distinct_id (a persistent machine identifier) and the write-only, public-by-design ingestion key are truncated above; payload_fields is the union observed across the run.

Reproduce it yourself (canary-sandbox (open methodology; Docker backend)):
python -m canary.cli scan <target> --backend docker # target: npm linear-mcp-server@0.1.0
Re-run it yourself: the scanner installs the pinned version, drives the tool over MCP, and intercepts all egress.

Full raw captured trace + verification: /verdict/linear/evidence.json — every captured request (redacted), the verdict content-hash and the package checksum, for an AI or auditor that wants the underlying observation, not just the conclusion.

Disclosure check (the §824 evidence)

Read
full npm tarball: build/index.js (919 lines), package.json, README; dependency grep for observability SDKs (none found)
Quoted from the tool's own docs
“”
Match
The only network destination is api.linear.app (Linear GraphQL API, https://api.linear.app/graphql) via @linear/sdk — exactly the API the tool exists to wrap. Zero telemetry/analytics/error-reporting: the entire published tarball (build/index.js + package.json + README) was read and grepped — no Sentry/PostHog/Segment/Amplitude/Mixpanel/Datadog/Bugsnag, no second host, no analytics strings; the only 'apiMetrics' is a LOCAL in-memory rate-limiter returned to the calling LLM, never transmitted; errors go to stderr only. Egress fires on tool-call (not launch), carrying the GraphQL operation plus LLM-supplied arguments (issue title/description, comment body, teamId, filters) and an Authorization header bearing the user's LINEAR_API_KEY.
Residual gap
This package (v0.1.0) is deprecated/unmaintained; its README redirects users to Linear's official remote MCP (mcp.linear.app). The README states the Linear-API purpose and the required LINEAR_API_KEY but does not name the literal host api.linear.app. Workspace/issue data lands in Linear's US cloud (deployer's GDPR transfer responsibility).

How we know this — claims by basis

Observed — directly in the capture, reproducible

Inferred — our reasoning over the observation

Classified — our adversarially-reviewed judgment

Method

Installed and run in an isolated container; fed traceable decoy data; all outbound traffic intercepted (TLS broken via own CA, iptables transparent redirect). Endpoints, resolved geo/jurisdiction and frequency are observed facts. Capture self-test passed.

Scope

Compares the tool's declared destinations against what was observed in one sandbox run. Checks transparency / integrity for a cooperative tool, NOT resistance to deliberate evasion. "honest"/"clean" means "observed without deviation within our reach", NOT "guaranteed no hidden egress". Out of scope: exfiltration split/chunked across requests; tool-side encryption of the payload before egress; input/time/state-triggered processing not triggered in the run.


Machine-readable verdict: /verdict/linear.json. This page describes observed behaviour and its relation to the tool's own disclosures — it is not a legal judgment. Search context: does linear-mcp-server send data, linear-mcp-server privacy, linear-mcp-server data flow, linear-mcp-server telemetry, where does linear-mcp-server send data, is linear-mcp-server safe, what data does linear-mcp-server collect, how to disable linear-mcp-server telemetry, linear-mcp-server opt out tracking, linear-mcp-server GDPR data residency, linear-mcp-server third-party / jurisdiction.