Litescope

What croc100/Litescope MCP server does

The croc100/Litescope MCP server connects MCP clients to local SQLite files and Cloudflare D1 databases, with support for Turso described by the project. It is intended for operational work rather than simple query execution: agents can inspect schemas, check database health, compare sources, plan migrations, investigate locks, and analyze performance issues.

The default posture is read-only. Write operations are unavailable unless the server starts with --allow-writes. Even then, mutating SQL and migrations are dry-run first, report affected rows and blast-radius information, and capture a recovery point before applying changes. Local databases use snapshots, while D1 uses a Time Travel bookmark. The resulting rewind_token can be passed to the undo operation.

How it works

By default, litescope mcp communicates over stdio, so it can be configured as a local MCP server in Claude Desktop, Claude Code, Cursor, Windsurf, or another MCP client. A database can be supplied when starting the server, such as litescope mcp ./app.db. The server also provides database-oriented MCP resources for schemas, data dictionaries, health, and lock diagnosis, along with prompts for workflows including migration review and locked-database diagnosis.

For remote or multi-client deployments, the server can use Streamable HTTP with --http. An HTTP token can require bearer authentication, and an origin allowlist helps protect the endpoint from DNS-rebinding risks. Without an HTTP token, the endpoint is open and emits a warning.

Query results include controls for maximum rows, selected columns, and truncation reporting. These limits help keep large result sets within an agent's context window. The implementation also exposes structured output, tool annotations, argument completion, resource subscriptions, and server logging under MCP 2025-06-18.

Setup and configuration

Install and start the server with npx -y litescope mcp for the standard stdio mode. Read-only use does not require the Cloudflare credentials shown in the project examples when working with local files. D1 access uses CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID; these are supplied in the MCP client's environment when needed.

Enable mutating operations by adding --allow-writes. This flag does not remove the dry-run and recovery-point behavior. To expose the service over HTTP, use the --http option and optionally set --http-token or LITESCOPE_MCP_TOKEN.

Tools and capabilities

Read-only capabilities include listing D1 databases, running SELECT statements, inspecting schemas, checking corruption and WAL or fragmentation conditions, comparing schemas and row counts, generating migration SQL, advising on indexes and scans, verifying backups, fingerprinting fleets, checking fleet health, diagnosing locks, and listing local snapshots.

Opt-in write capabilities include mutating SQL, applying migrations, optimization actions such as ANALYZE, index creation, and VACUUM, local snapshots and restores, D1 rewind operations, D1 pulls, and D1 database creation or deletion. The D1 deletion operation is irreversible according to the project documentation.

Limitations and notes

The safety workflow reduces accidental changes but does not make every operation reversible: D1 deletion is explicitly irreversible, and write access still requires deliberate server configuration. HTTP deployments need their own access controls; the documentation warns that an endpoint without a token is open. Cloudflare credentials are needed for the related D1 operations, while local SQLite work can be configured without them.

The project is distributed under AGPL-3.0. Its hosted dashboard is separate from the free, open-source command-line and MCP functionality described here.