Severity: Low (compliance/accuracy)
Files: app/privacy/page.tsx:33-39, app/privacy/page.tsx:77-85
Description
The published privacy policy makes a specific affirmative claim about logging:
The server logs only operational metadata for each request: the tool name
called, the HTTP status returned, and the response latency. It never logs tool
arguments [...]
No logging code exists anywhere in this repository. There is no logger, no
metrics emission, and no instrumentation of tool name, status, or latency;
createMcpHandler is configured with verboseLogs: false. Comments in
src/tools/index.ts and src/lib/bolna-client.ts:21-25 refer to logging "only
tool metadata elsewhere" — but there is no elsewhere.
The overclaim is in the harmless direction: the policy promises less privacy than
the code delivers, not more. It is still a factual inaccuracy in a document
published as the privacy policy for a distributed Claude Desktop extension
(mcpb/manifest.json:21) and an MCP registry entry, and it will drift further
out of sync if logging is added later without revisiting the page.
A second claim needs verification rather than correction:
If you connected via OAuth, you can revoke this server's access at any time
from your Bolna account's connected-apps settings
This asserts a user-facing revocation UI exists in the Bolna dashboard. Nothing
in this repo establishes that. If Supabase's OAuth client authorizations are not
exposed to end users there, the sentence promises a control users cannot
actually exercise, which is the kind of statement a privacy policy should not
make loosely.
Impact
Inaccurate statements in a published privacy policy are a compliance exposure
independent of whether the inaccuracy favors the user, particularly for a
connector distributed through a review process where the policy is part of the
submission.
Suggested fix
Either implement the described metadata logging, or rewrite the paragraph to
describe what the server actually does — a stateless pass-through with no
application-level logging, subject to the hosting platform's own request logs
(which do record request paths and timing, and should be mentioned since they
are real).
Confirm the connected-apps revocation path exists before the next release. If it
does not, replace that sentence with the mechanism that does work — revoking the
session or rotating the API key — and file the dashboard work separately.
Also align the contact address with the rest of the project; see the domain
mismatch tracked separately.
Severity: Low (compliance/accuracy)
Files:
app/privacy/page.tsx:33-39,app/privacy/page.tsx:77-85Description
The published privacy policy makes a specific affirmative claim about logging:
No logging code exists anywhere in this repository. There is no logger, no
metrics emission, and no instrumentation of tool name, status, or latency;
createMcpHandleris configured withverboseLogs: false. Comments insrc/tools/index.tsandsrc/lib/bolna-client.ts:21-25refer to logging "onlytool metadata elsewhere" — but there is no elsewhere.
The overclaim is in the harmless direction: the policy promises less privacy than
the code delivers, not more. It is still a factual inaccuracy in a document
published as the privacy policy for a distributed Claude Desktop extension
(
mcpb/manifest.json:21) and an MCP registry entry, and it will drift furtherout of sync if logging is added later without revisiting the page.
A second claim needs verification rather than correction:
This asserts a user-facing revocation UI exists in the Bolna dashboard. Nothing
in this repo establishes that. If Supabase's OAuth client authorizations are not
exposed to end users there, the sentence promises a control users cannot
actually exercise, which is the kind of statement a privacy policy should not
make loosely.
Impact
Inaccurate statements in a published privacy policy are a compliance exposure
independent of whether the inaccuracy favors the user, particularly for a
connector distributed through a review process where the policy is part of the
submission.
Suggested fix
Either implement the described metadata logging, or rewrite the paragraph to
describe what the server actually does — a stateless pass-through with no
application-level logging, subject to the hosting platform's own request logs
(which do record request paths and timing, and should be mentioned since they
are real).
Confirm the connected-apps revocation path exists before the next release. If it
does not, replace that sentence with the mechanism that does work — revoking the
session or rotating the API key — and file the dashboard work separately.
Also align the contact address with the rest of the project; see the domain
mismatch tracked separately.