Describe what can be queried: the six entities (game, team_game, team_season, player_game, player_season, play), their namespaces (e.g. prior., game., next.), and every attribute with its coverage window. Attributes are the only raw fields a plan may reference. Anything that is a concept rather than a field — "star", "starter", "injury", "blowout" — must be a term: see list_definitions and propose_definition.

The seasons a thing can answer for. Accepts table.column, entity.attribute, or the name of a definition. A query is refused when what it asks for reaches outside this window, so check here before promising a range.

The user's vocabulary. Every term used in a query must be here. Broken definitions (a column they depend on disappeared) are listed with the reason and cannot be used until fixed.

Everything about one definition: its spec, a nested English explanation of the definitions it is built from, the attributes it uses as evidence, its coverage, and its previous versions.

Call this when a query needs a concept that has no definition yet, or when query returns unresolved_term. Returns existing near-matches, ready-to-save candidate definitions grounded in what the data can compute (each with an English explanation and coverage), related attributes, and the five signal schemas for composing something new. Present the candidates to the user and let them choose or adjust. Do not pick one silently.

Save a definition the user has chosen. copy_of copies an existing definition (e.g. star_by_snaps) under a new name. Saving is versioned; previous versions are kept. Tell the user what was saved in plain English — the returned explanation is written for that.

Delete a definition. Its previous version is kept in history, so this is recoverable. Anything built on top of it becomes broken until it is replaced.

Dry run. Shows the English reading of the plan, which definitions it will use, the seasons it will cover, warnings, and the SQL. Use it to confirm your interpretation with the user before running an expensive or ambiguous query.

Run a structured query. plan is {entity, where, seasons, game_types, group_by, metrics, order_by, limit, allow_partial_coverage, sample_rows, question}; where clauses are {"term": name} for concepts, {"attr": name, "op": …, "value": …} for raw fields, and {"not"|"any_of"|"all_of": …} to combine. Every fuzzy word in the user's question must be a term. If a term has no definition this tool returns unresolved_term — do not replace it with an attribute rule to get past the error; call propose_definition and ask the user. The result includes definitions_used, the seasons actually covered, a sample of matched rows and the SQL; report the definitions and coverage alongside the number, because the number is not meaningful without them. If warnings mention evidence unavailable for early seasons, say so.

Escape hatch: read-only SQL over every raw and derived table (see describe_schema and coverage). A single SELECT or WITH statement, row cap, timeout, no file or network access. Results carry no definitions — prefer query for anything involving a concept, and tell the user when a number came from raw SQL. Every call is logged; recurring raw queries are how new attributes get prioritised.

What this server is running on: which database artifact, when it was built, the seasons it holds, whether the latest is still in progress, how many definitions exist and how many are broken.