codeDB Lens
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEDB_LENS_NO_UPDATE | No | Set to 1 to turn off the optional once-a-day version check against GitHub Releases. The CLI equivalent is --no-update-check. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| checkB | Run the codeDB Lens health check on a profile (read-only, 10-60 s): A-F grade with its coverage, findings with severity, confidence, evidence preview and next action, and rules without data. Saves the report in the profile's history, like the app does. |
| compareA | Compare two runs of the same instance: new, resolved and persisting findings and the grade change. Default: the two latest runs. Needs the user's free key (codedb-lens register). |
| describe_tableA | Columns (type, nullable, default), primary key, foreign keys with the referenced table, indexes and estimated rows of one table or view. Use it before writing a query, so column names are right. |
| explain_ruleA | Explain one rule: what it measures, why it matters, the next action, how to verify the fix, the permission it needs, its SQL and its documentation link. |
| get_findingA | Full detail of one rule in a saved run: status, impact, next action, how to verify the fix, and all evidence rows. Default run: the latest. |
| historyA | Saved check runs of a profile, newest first: date, grade, coverage and number of findings. Each run's path can be passed to get_finding or compare. |
| list_databasesA | Databases this profile's login can open: name, state, recovery model or encoding, collation and size in bytes. |
| list_profilesA | List the saved connection profiles you may use: name, engine, host, initial database and language. Never returns passwords or connection strings. |
| list_recordingsA | Recordings (activity sampled every 15 s for 1 or 24 h) kept with a profile's reports, newest first. Recordings made elsewhere can still be read with recording_report and their folder. |
| list_rulesA | List the Lens rule catalog (health checks): ID, engine, category, severity and title. Kind "series" rules judge recordings, the others run in a check. |
| list_tablesA | Tables and views visible to the profile's login in a database: schema, name, type, estimated rows, size and whether the login can read them. Start here, then describe_table, then query. |
| queryA | Run one read-only SELECT (or WITH ... SELECT) on a profile and get columns and rows. Aggregate in SQL (GROUP BY, TOP/LIMIT) instead of fetching raw rows: results stop at the profile's row limit (500 unless the user changed it), cells at 2 KB, and truncated: true means the answer is partial. Writes, EXEC, multiple statements and functions with side effects are refused; quote a column named like an SQL keyword. SQL Server reads uncommitted data, like the health check. |
| record_commandA | The command the user runs in a terminal (or on the server) to record a profile for up to 1 h, or 24 h with the free key. You cannot start a recording: give the user this command. |
| recording_reportA | Analyse a recording, optionally for a period (e.g. an incident): time coverage, gaps without data, findings as episodes (blocking, waits, long queries, workers or connections), peak of each chart and the top queries. Also writes the HTML report into the recording folder. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| diagnose | Run the health check on a profile and explain the biggest risks and what to do. |
| explore_data | Describe the tables of a database and suggest questions the data can answer. |
| incident | Read a recording over a period and explain what happened. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
The set forms a clear hierarchy (list_databases → list_tables → describe_table → query) and the analysis tools (check, history, compare, get_finding) are well separated. Two minor overlaps remain: get_finding vs explain_rule both return 'detail of a rule' (instance evidence vs rule definition), and check vs recording_report both produce analyses, though the descriptions do distinguish them.
A majority use verb_noun (list_tables, describe_table, explain_rule, get_finding, record_command), giving a recognizable pattern. But single bare words (check, compare, query, history) and a noun_noun (recording_report) break it, making it mixed though still readable.
14 tools is squarely in the well-scoped range, and each maps to a distinct step in the DB health-check workflow (discover, inspect, query, check, review, record). Nothing appears redundant or padding.
Covers schema exploration, read-only querying, rule catalog, health checks, run history/compare, and recordings — a full read/analyze lifecycle. Minor gaps: no profile create/edit/delete (presumably managed in the app) and no rule search/filter, but agents can work around these.