Skip to main content
Glama
codedb-io

codeDB Lens

Official

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
CODEDB_LENS_NO_UPDATENoSet 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

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription
diagnoseRun the health check on a profile and explain the biggest risks and what to do.
explore_dataDescribe the tables of a database and suggest questions the data can answer.
incidentRead a recording over a period and explain what happened.

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.8/5.0

Scored across 14 tools

Disambiguation4/5

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.

Naming Consistency3/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues