Start here. Lists every datasource with whether SQL can run against it, how much of it is modeled (Terms, relationships, SQL attributes) and what to do next.

Register a database (connections are always read-only) and, by default, scan it. Use only when the user gives you a connection URL; never invent credentials.

Read (or re-read) tables, columns and declared keys; profile column values (samples, uniqueness, date formats, small value sets); infer undeclared primary/foreign keys by name and confirm them by value containment. Existing Terms and reviewed relationships are kept.

Next tables that still need business Terms, with everything needed to name them: candidate columns with types, sample values, uniqueness and formats, foreign keys and the Terms they point to, plus the modeling rules. Then call save_table_terms once per table. Repeat until remaining is 0.

Save the Terms you propose for one table and map its columns to them. Replaces this table's previous Terms (Terms with SQL attributes are kept). New Terms start as draft; editing a certified Term's meaning returns it to draft. Unassigned candidate columns are attached to the first Term.

Joins between tables with their evidence (declared, inferred by name and value containment, or added manually), roles when several columns point at the same table, and identifier columns that have no relationship yet. Review proposed ones with set_relationship.

Accept, reject, add, annotate or delete a join between two columns. Reviewed relationships survive re-scans. Only accepted relationships are used for join paths.

Candidate SQL attributes (reusable measures, filters, join patterns) mined from executed and verified queries, bridge tables and column profiles, with the rules for judging them. Save the good ones with save_sql_attribute.

Create, update, certify or delete a named SQL expression under a Term. The expression is executed read-only against the database before it is saved, so a broken one is rejected with the error.

Edit, certify, deprecate or delete a Term. Changing the name or description of a certified Term returns it to draft unless you also pass status.

Maintain the glossary of abbreviations and internal jargon (MRR → monthly recurring revenue). Glossary entries are returned with query context and searched like Terms.

Create an entity in the personal knowledge store (a Term with its own table), add columns to it as you learn more, or delete it. Column types: text, integer, number, date, datetime, boolean, ref: (a link that becomes a relationship). Every record also gets id, _source_id, _source_locator, _evidence, _note and timestamps.

Storing knowledge (Auto Ontology's model applied to personal knowledge):

1. Reuse before you create: search_ontology for the thing first. One Term per real-world kind of thing, named in the singular as people say it (Receipt, Book, Person, Workout).

2. Entities hold facts you will count, sum, filter or compare. Give columns snake_case English names and the right type (text, integer, number, date, datetime, boolean, ref:). Put the unit in the name or description (amount_krw, distance_km). Use ref columns for things that recur (merchant, author, place) instead of repeating text; add_records creates the referenced rows by name. Set keys when a natural identifier exists (isbn, receipt_no) so re-ingesting updates instead of duplicating.

3. Concepts hold meaning: a one-sentence definition, a markdown body (what it is, how it works, examples, open questions) and typed relations: is_a, part_of, has_part, instance_of, related_to, depends_on, causes, used_for, contrasts_with, same_as, example_of. A Term can be both: an entity with records and a body that explains it.

4. Provenance on everything: pass source={title, kind, uri, ...} (or a source id) and, per record, _locator (page, timestamp, line) and _evidence (the quote or number as written).

5. Never invent values. Leave unknown fields out; record ambiguity in _note.

6. Certified means a person confirmed it. New knowledge is draft; do not certify on your own.

Store facts you extracted from what the user shared (receipts, statements, reading notes, logs). All records are validated first; if any is wrong nothing is written and every problem is listed. Records matching existing ones by key (or identical ones) update or are skipped instead of duplicating.

Correct or delete records by id. Deleting a record that other records reference is refused. Confirm with the user before deleting.

Create or update a concept: a Term with a definition, a markdown body (a wiki page) and typed relations to other Terms. Works on entity Terms too, to explain them. Targets that do not exist yet become empty concepts to fill in later.

One source with its summary and content, and everything stored from it: records per entity, concepts and relations. Use it to cite where an answer came from.

The index of a datasource: every Term (entities and concepts) with its one-line definition, status, synonyms, record and relation counts, and which concepts are still empty. Read it before adding knowledge, to reuse Terms instead of creating near-duplicates.

The log: what was added, changed, certified or deleted recently, newest first.

Write the ontology (by default the knowledge store) as markdown pages that Obsidian can open: one page per Term with synonyms as aliases and relations as [[links]], one page per source, an index.md and a log.md. The folder is ~/.auto-ontology-mcp/wiki/; re-exporting replaces generated pages only. It is a one-way view: edits made in Obsidian are not read back.

Lexical search across Terms (entities and concepts, including their bodies and relations), synonyms, mapped columns, SQL attributes, glossary, verified example questions, sources (title, summary, content) and unmodeled tables. In the knowledge store it also finds records by their stored text ('value' hits; request kind 'value' to search another datasource's data). Not semantic: use the schema's vocabulary, try synonyms, translate.

One Term: definition, status, synonyms, mapped columns with sample values and formats, SQL attributes and related Terms with their join conditions and multiplicity.

A physical table with its Terms, columns (and the attributes mapping them), relationships and SQL attributes.

Shortest chain of accepted relationships between two Terms or tables, with ON conditions, a ready FROM/JOIN clause, fan-out warnings and alternative roles (e.g. billing vs delivery city).

Cheap pre-flight: does the ontology cover every entity of the question? Returns coverage, a verdict (answerable, uncertain, partially_answerable, not_answerable) and the best matches per entity. When something material is not covered, tell the user instead of substituting a similar measure.

Everything needed to write the SQL: qualified tables, mapped columns with sample values and formats, SQL attributes, the join path connecting the Terms (with a ready FROM/JOIN clause and role notes), verified example queries, glossary and the SQL rules for this dialect.

Real values stored in a column, to ground literal filters ('Pennsylvania', a product name, a status code) before you write them into SQL.

Check a query before running it: read-only guard, unknown tables/columns, joins that are not (or not the default) relationships in the ontology, wrong-looking literals (near-miss values, percent vs fraction), one-to-many fan-out under SUM/AVG/COUNT, and a dry run. Also reports which Terms the query relies on and whether they are certified.

Execute a read-only query and return columns, rows, row_count and truncated, plus the Terms it used and warnings. Writes, DDL and multiple statements are refused; the connection itself is read-only. Present the SQL with the answer and say when results are truncated.

Store a question and SQL pair the user confirmed as correct. Verified examples are offered by get_query_context for similar questions and mined by suggest_sql_attributes.

The whole semantic layer of a datasource as one YAML/JSON document (Terms, column mappings, SQL attributes, relationships, glossary, example queries), for review or version control.

Apply an exported document to a scanned datasource (matching tables and columns by name).

Search the ontology documents (Terms and tables) across all datasources. Returns ids for fetch.

Full text of one ontology document (a Term with its attributes, SQL attributes and relationships, or a table).