CallLint

Gemini CLI

CallLint support for Gemini CLI by Google. CallLint scans the mcpServers map in Gemini CLI settings. OAuth token and server-enablement files are read for neither discovery nor verdicts.

P2 Auto-detects

Why scan Gemini CLI?

Gemini CLI exposes MCP servers as tools it may select autonomously, so registration and invocation are separated in time — the review has to happen at registration.

Usage

CallLint can auto-discover and scan Gemini CLI configurations:

calllint scan --agent gemini-cli

How to start

Install nothing globally — run CallLint straight from npm:

npx calllint scan --auto

Then scan Gemini CLI specifically:

calllint scan --agent gemini-cli

How to verify it worked

Read the credential findings first. Gemini CLI keeps server registration in the same settings file as its own auth, so an entry that carries env keys is asking for authority the agent can spend later without asking again.

What CallLint does to Gemini CLI

Offline by default. Deterministic. Never executes the server it judges. SAFE means no blockers observed, not a proof of runtime safety.

A No blockers observed verdict means exactly that — no blocker under the evidence CallLint could collect. It is not a guarantee, and Insufficient evidence never becomes it on its own. See Coverage Boundary for what this scan does not look at.

Configuration Paths

CallLint looks for Gemini CLI configurations in:

  • ~/.gemini/settings.json
  • <project>/.gemini/settings.json

Authority Surfaces

Gemini CLI can grant tools the following authority surfaces:

  • mcp
  • tools

Distribution

CallLint is available for Gemini CLI through:

  • mcp-stdio (via officialMcpRegistry) — Listing not yet verified
  • gemini-extension-gallery — Listing not yet verified
    Audit resolved 2026-08-27; the state stays unverified because what remains is our own work, not a queue. There is no submission here at all: the gallery automatically indexes public repositories and the docs say in as many words that you need not submit an issue or email anyone. Three conditions, quoted from the releasing guide: the extension is hosted in a public GitHub repository; the repository carries the `gemini-cli-extension` topic, which is what the crawler uses to find new extensions; and `gemini-extension.json` sits in the absolute root of the repository or the release archive. Crawling is daily and listing is conditional on passing validation. No git tag or release is required — `migratedTo` is the only transition that needs one. So the first condition already holds, the third is an artifact this repository does not yet have, and the second is a one-call metadata change. Ordering matters and is the reason this is not done: adding the topic first invites a daily crawler to validate a repository with no manifest in it, and a listing that depends on passing validation should not first be observed failing it. Manifest before topic.

Support Status

Auto-detects — CallLint finds this host’s config on its own.

The commands under Usage are the ones CallLint actually supports for Gemini CLI today. Anything not listed there is not claimed.

Official Sources

Coverage Boundary

CallLint scans the mcpServers map in Gemini CLI settings. OAuth token and server-enablement files are read for neither discovery nor verdicts.