mcp-firebird

You can also hand it a goal,"this query must stop scanning NATURAL","it has to come in under 200 ms", and let it work: it applies a change, measures it again on the database, and tries again if that was not enough. What decides the goal is met is the measurement, not the assistant.

These are not the generic index tips you can find in any article. The answers come out ofyourdatabase: the server asks Firebird for the query's execution plan (SET PLANONLY), queries the monitoring tables (MON$), and counts how many distinct values a column really holds before claiming an index on it would pay off.

Every answer arrives in three parts.Finding: what it found, and why it is a problem.SQL: the statement that fixes it, already written.Verify: how to check the fix actually worked. No tool writes to the database. The server reads, and the SQL it hands you is yours to run, when and if you decide to.

Tools (10 free, plus 9 Enterprise announced intools/list)

Every advisory comes with aFinding, ready-to-runSQL, and aVerifystep. Every analysis tool also closes withwhat it does not rule out: a plan cannot see contention, a snapshot cannot see accumulation, and a clean answer to a narrow question is not a clean bill of health.

Whatfb_suggest_indexesdecides, and in what order

An index is not free: it is written on every INSERT, UPDATE and DELETE into that table, for as long as it exists. So the advisor proposes thecheapest remedy that explains what the plan did, and it is willing to propose nothing at all.
- Refresh, don't build.Firebird stores an index's selectivity when the index is created and never recalculates it. An index that exists and is ignored may be ignored because the optimizer is costing it against last year's data — and answering that with a second index leaves the database paying for writes forever because a number needed refreshing. Nothing here says"the index is not used, and that is correct"until the stored figure has been compared with the real one.
- Wake, don't duplicate.AnINACTIVEindex over the column the query filters by isALTER INDEX … ACTIVE, never a second index beside the sleeping one.
- Say when the scan is right.The query is executed once and the records it read are compared with the rows it returned. A scan that keeps most of what it readsisthe correct plan, and so is a scan of a table small enough to be a handful of pages: both come back as a finding with the numbers andno SQL to run.
- Then, the right shape.UPPER(NAME) = ?cannot use a plain index at all and gets an expression index, with the expression emitted exactly as written — Firebird matches it only on an exact match.STATE = 'ACTIVE' AND TAG = ?gets an index on what it seeks by, plus the partial form on 5.0+, which indexes only the population the query looks at.ORDER BYon an unindexed column gets an index whose segments match itin its own direction— and a plain statement that no single index servesORDER BY a ASC, b DESC, rather than one that would never be used.

Note:to measure, this toolexecutes the queryit is asked about — once, inside the read-only transaction, and only when the plan actually shows a scan or a sort. On a large table that is a full scan. It never executes anything that is not a plain SELECT, and it does not execute a statement with unbound parameters at all: those bind as NULL, match nothing, and would produce a measurement of a query nobody runs.

- optimization_goal, the goal-driven loop: set an objective, the assistant iterates thefb_tools and re-checksfb_evaluate_goaluntil it reportsmet: true(with a max-iterations / no-progress safety stop).
- health_check: guided whole-database health review.
- classify_problem: starts from the symptom, not from a tool. Places the problem on six axes (temporal shape, volume vs concurrency, locality, coordination vs execution, sensitivity to observation, environment), names the dominant class of the seven, and says which reasoning converges on it — including when the answer is that an SQL connection cannot settle it. Follows the taxonomy in Cisar & Reeves,Practical Firebird Performance Diagnostics(IBPhoenix, 2026).

Then one day it comes back and tells you the truth:your schema is fine. Your indexes are fine. No natural scans, no external sorts, statistics fresh.And the database is still slow.

Note what isnotin that table: nothing was moved out of the free edition to build the paid one. Every free tool stays free, and the ones still to be written stay on the side of the line they belong to. The boundary is not a paywall drawn through a feature list. It is the line between querying a database and administering a server, and the free edition was always on one side of it.

The hard part was never parsingfirebird.conf; anyone can parse an INI file. And nobody can honestly hand you the right value forLockHashSlots:Firebird's own documentation states no optimum for it, nor for the page cache, nor for the sort cache. What experience buys you is knowingwhichparameter your symptom implicates: that throughput collapsing under concurrency while the CPU stays calm points at the lock table and never at the page cache. That map is the product. The value at the end of it is not asserted. It is measured, on your database, under your load.

By default the.envis read from the executable's own folder. Pass--env <dir>to read it from another folder instead. The argument is adirectory(the folder thatcontainsthe.env), not the file itself:

MCPFirebird.exe --env C:\configs\prod # reads C:\configs\prod\.env MCPFirebird.exe --env=C:\configs\prod # the --env=<dir> form also works MCPFirebird.exe --env ..\shared # relative paths resolve against the working directory MCPFirebird.exe # no argument -> reads <exe folder>\.env MCPFirebird.exe --env C:\configs\prod\.env # WRONG -> stops with an error (see below)

MCPFirebird: --env must point at the FOLDER that contains the .env file, not at the file itself. got: C:\configs\prod\.env use this: C:\configs\prod

Boot: .env directory "C:\configs\prod" (.env exists=True)