This server lets you analyze Firestore databases for schema, security, performance, and cost issues — giving AI agents ground-truth database knowledge before writing code. It provides three tools:
lintbase_scan: Runs a full scan of your Firestore database to detect schema drift, security vulnerabilities (e.g., no auth), performance problems (e.g., large docs), and cost leaks (e.g., large collections). Returns a structured report with a risk score and prioritized, actionable issues.
lintbase_get_schema: Samples real Firestore documents to retrieve the actual schema of one or all collections, including field names, observed data types, and presence rates. Helps AI agents avoid hallucinating field names before writing database code.
lintbase_get_issues: Runs all analyzers and returns a filtered list of issues. Supports filtering by severity (error, warning, info), collection name, or rule prefix (schema/, security/, perf/, cost/). Lighter-weight than a full scan — returns only actionable issues without summary metadata.
All tools accept a Firebase service account key path and optional sample size/collection filters to control scope and cost.
Provides real-time Firestore schema context to AI agents, enabling accurate database queries and security rule validation.
Provides real-time MongoDB schema context to AI agents, enabling accurate database queries and schema validation.
Ground Truth for AI Coding Agents. LintBase gives AI agents real-time knowledge of your database schema, security rules, and architecture so they stop hallucinating your codebase.
npx lintbase export-context firestore --key ./service-account.json
Developers are constantly feeding context files to AI tools like Cursor, Windsurf, Copilot Workspace, and Claude Code. If your agent doesn't understand your real database schema, it writes code that fails in production.
LintBase acts as the bridge. It connects directly to your database, reads the ground truth of your live documents, and generates structured context optimized for AI.
🤖 Stops AI Hallucinations — Generates exact schema, field presence rates, and types.
📐 Catches Schema Drift — CI protection with lintbase check against schema snapshots.
🔒 Security Context — Highlights missing rules or exposed PII before your AI writes queries.
💸 Cost Awareness — Prevents AI from writing unbounded queries on 2M+ document collections.
🍃 Universal NoSQL — Works effortlessly with Firestore and MongoDB.
Because in document databases, the code lies. The real schema is whatever your live documents actually contain, and that drifts away from the code with every half-finished migration, every renamed field, and every previous AI session that wrote in a hurry. An agent inferring the schema from TypeScript interfaces writes plausible queries against a database that no longer exists. The failure is silent: empty results, undefined values, a new field variant living alongside the old one. LintBase reads the documents, not the code.
Firestore and MongoDB only. Postgres is the obvious gap and it is next.
Large collections are sampled, not fully scanned. Presence rates are estimates on multi-million-document collections.
The MCP server is newer than the CLI. Expect rough edges there first.
Related MCP server: Carto MCP Server
The fastest way to give your AI agent perfect database knowledge.
npx lintbase export-context firestore --key ./service-account.jsonOutput:
/lintbase-context/
├── database-schema.md
├── collections.md
├── security-rules.md
├── architecture.md
└── risk-report.mdDrop the lintbase-context folder into your AI's context window, or mention it in .cursorrules. Your agent will now write perfect, drift-free database queries.
Firebase Console → Project Settings → Service Accounts → Generate new private key
Save the JSON file. Never commit it to git.
LintBase acts as "Version Control for your Schema". Run the snapshot command to create a baseline:
npx lintbase snapshot firestore --key ./service-account.jsonCommit .lintbase/schema.json to your repository. Then, add the check command to your CI/CD pipeline (GitHub Actions, GitLab CI):
npx lintbase check firestore --key ./service-account.json --fail-on errorIf a query or deployment accidentally deletes a critical field or changes a type (e.g., string to number), your CI build will fail instantly.
npx lintbase scan firestore --key ./service-account.jsonYou'll see a full report in your terminal:
LintBase — Firestore Scan
─────────────────────────────────────────────
Collections scanned: 12
Documents sampled: 847
Issues found: 23 (4 errors · 11 warnings · 8 infos)
Risk score: 67 / 100 [HIGH]
ERRORS
✖ users no-auth-check Documents readable without authentication
✖ orders missing-index Query on `status` + `createdAt` has no composite index
✖ debug_logs large-collection Collection has 2.4M docs — estimated $340/mo in reads
WARNINGS
⚠ products schema-drift Field `price` found as both Number and String
⚠ sessions ttl-missing No expiry field — stale docs accumulate indefinitely
...Track your database health over time at lintbase.com:
npx lintbase scan firestore \
--key ./service-account.json \
--save https://www.lintbase.com \
--token <your-api-token>Get your token at lintbase.com/dashboard/settings.
Firestore: npx lintbase scan firestore --key ./sa.json
MongoDB: npx lintbase scan mongodb --uri mongodb+srv://user:pass@cluster.mongodb.net/test
Using Cursor, Claude Desktop, or Windsurf? Install lintbase-mcp to give your AI agent real-time Firestore schema context — so it stops hallucinating field names.
Add to .cursor/mcp.json:
{
"mcpServers": {
"lintbase": {
"command": "npx",
"args": ["-y", "lintbase-mcp"]
}
}
}Now when you ask your AI "add a field to users", it will check your real schema first before writing a line of code.
→ Full setup guide & tools reference
Rule | What it detects |
| Collections readable/writable without auth |
| Email, phone, SSN fields without encryption markers |
| Documents with overly permissive security rules |
Rule | What it detects |
| Collections with 100k+ docs and high read cost |
| Queries without |
| Filter combinations that fall back to full collection scans |
| Collections that look like temporary data that was never cleaned up |
Rule | What it detects |
| Field stored as different types across documents |
| Field present in 90%+ of docs but absent in some |
| Reference fields that are sometimes null |
Rule | What it detects |
| Document fields nested > 3 levels deep |
| Documents approaching the 1MB Firestore limit |
| Single document updated by many users simultaneously |
| Collections without a standard pagination field |
lintbase <command> <database> [options]
Commands:
scan <database> Scan a database and print diagnostic report
export-context <database> Export schema to markdown/JSON for AI agents
snapshot <database> Generate local schema snapshot for CI comparison
check <database> Run in headless CI mode (fails on schema drift)
Options:
--key <path> Path to Firebase service account JSON
--uri <uri> MongoDB connection URI
--limit <n> Max documents to sample per collection [default: 100]
--max-depth <n> Firestore: tiers to recurse into subcollections
(1 = top-level only) [default: 2]
--fail-on <lvl> Fail pipeline if issues exceed severity (error, warning, info)
--save <url> Dashboard URL to save results
--token <token> API token for dashboard (from lintbase.com)
--collections Comma-separated list of collections to scan
-h, --help Show helpThe CLI is free forever. The dashboard visualizes your scan results as an interactive schema map — your credentials never leave your machine.
What Pro gets you via --save:
⬡ Schema Map — every collection as a draggable card, with real field names, types, presence rates, and issue badges
◎ Health Radar — per-collection spider chart across Schema, Security, Performance, and Cost axes
⊕ Priority Quadrant — 2×2 bubble chart of Impact vs. Ease of Fix — tells you what to fix first
≋ Drift Timeline — stored history across scans so you can replay your schema architecture over time.
CLI Local Tooling: 100% Free · Pro: $39/month — unlimited history, dashboards, and shared team workflow.
Your service account key never leaves your machine — it is only read locally
Document sampling is hard-capped at --limit (default 100) to prevent accidental read costs
The --save flag only sends the scan summary and issue list — never raw document data
MIT © Mamadou Dia
Runs all LintBase analyzers and returns a filtered list of issues. Use this for targeted questions like "any errors in users?", "schema issues only?", or "all security problems?". Lighter than lintbase_scan — returns only actionable issues, no summary metadata. Filter by severity (error/warning/info), collection name, or rule prefix (schema/, security/, perf/, cost/).
| Name | Required | Description | Default |
|---|---|---|---|
| rule | No | Filter by rule prefix, e.g. "schema/" returns only schema drift issues, "security/" only security issues. | |
| keyPath | Yes | Absolute or relative path to the Firebase service account JSON file. | |
| severity | No | Filter by severity. Omit to return all severities. | |
| collection | No | Filter to a single collection name. Omit to scan all collections. | |
| sampleSize | No | Max documents to sample per collection (default: 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that the tool runs all analyzers, returns only actionable issues, and lists filtering capabilities. It does not mention side effects or authentication details beyond the required keyPath.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with main purpose, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 5 parameters and no output schema, the description covers main purpose and filtering hints. Missing return format details, but adequate given scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description reinforces parameter usage with examples but adds little beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Runs all LintBase analyzers and returns a filtered list of issues,' providing a specific verb and resource. It further differentiates from sibling tools by contrasting with lintbase_scan, which returns summary metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage examples ('targeted questions like ...') and contrasts with lintbase_scan. While it doesn't specify when not to use, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the ground-truth schema of your Firestore collections by sampling real documents. For each collection you get field names, observed types, and presence rates. Use this BEFORE writing any database code to avoid hallucinating field names. Stable fields (≥80% presence, single type) are safe to use. Fields marked with a note need attention (drift, sparse, or optional).
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format. Use "md" to write Obsidian-compatible Markdown files to disk. | |
| keyPath | Yes | Absolute or relative path to the Firebase service account JSON file. | |
| outPath | No | Path to write Markdown output. For a single collection: full file path (e.g. "./docs/schema/users.md"). For all collections: directory path (e.g. "./.lintbase/schema"). | |
| collection | No | Name of a single collection to inspect. Omit to get the schema of ALL collections. | |
| sampleSize | No | Max documents to sample per collection (default: 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Discloses sampling behavior, field details (names, types, presence rates), and stable field criteria. Doesn't mention side effects or permissions, but implies read-only operation. Adequate for a schema inspection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, efficient structure. Every sentence delivers value: purpose, usage advice, field interpretation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return data (fields, types, rates). However, ambiguity exists: description says 'Returns schema' but format param writes Markdown to disk; unclear if tool returns data or only writes files. Missing explanation of output mode.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
100% schema coverage meets baseline. Description adds usage context (e.g., 'Use this BEFORE...') but does not elaborate on individual parameters beyond schema. Marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb and resource: 'Returns the ground-truth schema of your Firestore collections by sampling real documents.' Distinguishes from siblings (lintbase_get_issues, lintbase_scan) by focusing on schema discovery rather than issues or scanning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use 'BEFORE writing any database code to avoid hallucinating field names.' Provides interpretation guidelines for fields (stable vs need attention). Lacks explicit when-not-to-use or comparison with siblings, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a full LintBase scan against a Firestore database. Detects schema drift, security issues, performance problems, and cost leaks. Returns a structured report with a risk score and actionable issues. Use this before writing any database-related code to get ground-truth schema context.
| Name | Required | Description | Default |
|---|---|---|---|
| keyPath | Yes | Absolute or relative path to the Firebase service account JSON file. | |
| sampleSize | No | Max documents to sample per collection (default: 50, max: 500). | |
| collections | No | Optional list of collection names to scan. Omit to scan all collections. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as a scan that detects issues, implying read-only behavior, but does not explicitly state whether it modifies data, what authentication is required, or potential performance impacts. The lack of explicit safety declarations is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that are front-loaded and each sentence earns its place: action, detections/returns, and usage guidance. No wasted words, efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description states the output is a structured report with risk score and actionable issues, but lacks details on the report structure or error handling. For a scan tool that produces a complex report, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: keyPath, sampleSize, and collections are all described in the schema. The description does not add additional meaning beyond what the schema provides (e.g., it doesn't explain sampleSize constraints or collection format). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'runs a full LintBase scan' against a Firestore database, listing specific detections (schema drift, security issues, etc.) and outputs (structured report with risk score). It distinguishes itself from sibling tools by emphasizing 'full scan' and 'ground-truth schema context', implying it covers everything that sibling tools might offer individually.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this before writing any database-related code to get ground-truth schema context', providing a clear when-to-use recommendation. It does not, however, specify when not to use it or directly contrast with sibling tools for narrower use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0lintbase_get_issueslintbase_get_schemalintbase_scanThe three tools are largely distinct: lintbase_get_issues returns filtered issues for targeted queries, lintbase_get_schema returns schema information, and lintbase_scan returns a full report. Some overlap exists between get_issues and scan (both yield issues), but clear descriptions mitigate confusion.
All tools use the 'lintbase_' prefix and snake_case. Two follow the 'get_X' pattern (get_issues, get_schema), while the third uses a bare verb (scan). This slight inconsistency prevents a perfect score, but the pattern is still clear and readable.
With three tools, the surface is well-scoped for a linting/analysis service. Each tool serves a distinct purpose: schema retrieval, filtered issues, and full scans. No tool is redundant, and the count is appropriate for the domain.
The tool set covers core analysis needs: obtaining ground-truth schema, running comprehensive scans, and querying specific issues. There are no obvious gaps for typical development workflows involving Firestore linting.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Lints + auto-fixes how AI coding agents discover any new product. 24 rules, 6 tools, score 0-100.
Research-backed linting + generation for agent context files (CLAUDE.md, AGENTS.md, Cursor rules).
Turn PRDs and product ideas into structured specs so coding agents build your intent, not theirs.
Database for your AI agent. Turn its output into data, docs, skills, and apps you can actually use.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lintbase/lintbase'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
